ubuntu-appstore-developers team mailing list archive

[James Tait <james.tait@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/06/13 13:16, Roberto Alsina wrote:
>> On Mon, Jun 24, 2013 at 6:56 AM, James Tait
>> <james.tait@xxxxxxxxxxxxx <mailto:james.tait@xxxxxxxxxxxxx>>
>> wrote:
>> 
>> On 21/06/13 16:05, Martin Albisetti wrote:
>>> So, translations. I've been talking a bit with the people
>>> closer to the potential customers for the Ubuntu Phone, and it
>>> seems we will need to have a basic i8n story in place after
>>> all.
>> 
>>> Thinking about the simplest way possible, and since the
>>> relevant metadata (description, etc) will be entered and live
>>> on the server, I'd like to explore us just having a simple
>>> toggle on the web ui that switches between languages and people
>>> can type in (or paste) the text for each language. I'd like to
>>> explicitly exclude any automation for metadata translations for
>>> the moment as that would be much more complex. Also, this
>>> discussion excludes the actual application's translations.
>> 
>>> So, Matias, Ricardo, Michael, James, what would we need to do
>>> in order to support this both on the MyApps side and on the
>>> search index side of things?
>> 
>> Well, I know Solr offers at least some level of support for
>> multiple languages in its TextField, but I'm not sure exactly how
>> it works.  At a high level, I think we could index localised
>> fields one of two ways:
>> 
>> - one field per language, with a suffix on the field name, e.g. 
>> description_en = "My awesome app" description_fr = "Mon app trés
>> bien." - one multiValued payload field, keyed on language, e.g. 
>> description = [ 'en|My awesome app", 'fr|Man app trés bien" ]
>> 
>> The problem with the latter approach, as I currently understand
>> it, is that it would be indexed on the language key, so I'm not
>> sure if we'd be able to search on the actual localised
>> description text.  On the other hand, it does make the
>> localisation mostly transparent - we just select the description
>> field regardless of the language we want, and probably return the
>> appropriate version based on the request headers or an optional
>> query parameter, rather than having to mangle the request to
>> append the localisation suffix to field names.
>> 
>> We have a similar consideration with the price field and its
>> currency, and I want to get to the bottom of both of these
>> problems as soon as possible - they're the biggest unknowns for
>> me at this stage.
>> 
>> JT
> 
> I suppose from the client side we don't much care which way it's 
> implemented. We get the current locale, we query using it (or not),
> and display the correct string.

Yes, from the client side I wouldn't expect you to have to worry about
it at all, really.  At least I'll try to make it that way.  I'm not
sure how we deal with a request for a field that doesn't have the
requested localisation (maybe we just return the default, whatever
that is), but otherwise it should be transparent, I think.

JT
- -- 
James Tait, BSc. | https://launchpad.net/~jamestait/
Software Engineer, Canonical Online Services, Web and Ops Team
Ubuntu - Linux for human beings | www.ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHIQuwACgkQyDo4xMNTLiZHswCg140qoC4EQaqd6GQAMkqHPSQJ
ltMAnRBlRcrvtGzbJgFRZLy+k0ODX5T9
=A+C+
-----END PGP SIGNATURE-----