in homescreen1 we used properties files: https://github.com/EverythingMe/gaia/blob/master/apps/homescreen/locales/collections.en-US.properties

Cristian, maybe you can take this as you did excellent work with homescreen1 :)

Sorry but I have a lot of work with the migration right now mate

looping :chofmann as :cserran suggested - your feedback on using .properties files? (see description)

Hi Amir, I'm not exactly sure what the question is. In general using .properties files is fine, but I'd need a bit more contest. Are collections for vertical homescreen different from the ones we're currently using?

(In reply to Francesco Lodolo [:flod] from comment #4) > Are collections for vertical homescreen different from the ones we're > currently using? In the vertical homescreen collections are sync over the Datastore by the Collections app. There will be a build process which will create the initial, pre-installed Collections (bug 1016225). When a user later changes the locale, the names of the pre-installed collections should update. The question is - how should we provide these translations? In the old homescreen we used the .properties files I linked to. We can do the same for the Vertical homescreen unless there a better solution.

(In reply to Amir Nissim (Everything.me) from comment #5) > In the old homescreen we used the .properties files I linked to. We can do > the same for the Vertical homescreen unless there a better solution. I don't think we have alternative solutions. .properties files are automatically extracted and exposed to localization tools and localizers, so that's definitely the way to go to have those names localized.

We definitely want to use a properties file to localize the strings. For the locale change, I think one option that might be worth investigating is to see if we can populate a "manifest-like" thing from the collections app. On locale change, we can then have the homescreen perform the localization. So in addition saving the name and pinned results, we could also save a map of string - the same way a mozApp result works. This does create a bit of complexity when we do save the collection, and we would need to know the available locales on the device. Another option would be to fire an IAC message and have the collections app update each object's name attribute - the datastore sync would just take care of everything.

Amir, This all seems very complicated, and I might be misunderstanding, but I think your question is about how should the localization of "collections" appear when the user changes locale. I've take a crack at recapping my understanding of the issues based on the things you said above. Feel free to correct any of this. The complication is that there is an initial build list of collections (.properties file), then the collections list gets updated from marketplace in a synching process (that works using jason for the transfer?). So this will mean there should be two sources of "collection lists" for each locale as well. One in the initial build, and one on market place that the collection app synch's up with. If a locale change has been made it seems a reasonable UX response should be to go directly to the "collection list" from marketplace, rather than going to the initial build collection list, then updating to the marketplace collection list. Does that summarize how you expect this to work? Marketplace gets localized by pei mo and clouserw. They will have the best idea on how to get collection lists localized and stored on market place that the collection app would synch with.

Just throwing randomly uneducated thoughts into the pot: This sounds like the contacts API problem, where each consumer of the contacts API needs to localize the field names. That is indeed a challenge in API design, and if you're having a data-based api like datastore, then, yes, each consumer of that api will need to localize each data item from scratch.

is it possible for an inactive app to observe the device locale? if there is a way to do that, then the collection app can run a background process when the locale changes, update the datastore and the homescreen will update by the datastore bindings. this way we can re-use the locale files already in the collection app.

How often will collections change? For things like: Showbiz = Showbiz Social = Social Games = Games Music = Music It seems like not very often. I suspect locale switching happens pretty infrequently as well, but maybe telemetry could tell us something about that. Is there a UX design for this? If all the data changes infrequently the design of this for data updates and synchronization might want to follow that idea and be as simple as possible.

From my point of view: 1) User changes the locale En -> Es 2) Homescreen (or system,...) is listening when it happens and via IAC send a message to collection app, hey app "localize" please. 3) The collection app gets locales and via .properties file changes the names for collections in the datastore 4) Automatically all homescreens running or any app listening for changes on the datastore should update labels What do you think guys? Thanks a lot

(In reply to Cristian Rodriguez (:crdlc) from comment #12) sounds good. when we have steps 1 and 2 implemented I can it from there...

I could take care of the first step but I like to know which app should do it, vertical-home or system, kevin?

The homescreen may not be running, so we would need to store the last locale in asyncStorage or something, then check that it's still the same on startup - and if not send a message. It also seems like a lot of work if third party homescreens need to do this. FWIW - I still like the idea of reading from shared/resources/languages.json and populating a manifest-like with all possible translations on create. It's more complex during create time, but lowers runtime complexity which I like.

Kevin - Should we call this feature work or a bug? Just want to know which flag I need to set here.

However you want to track it. It's part of the feature but also a bug :) Feature work I guess because it's not a regression?

Okay - Candice - Can you add the feature-b2g flag here?

Okay- I am going to take a shot at this.... My plan looks like this: At build time generate .json files which contain a locale manifest (like the mozapps do) this information will be read directly from our localization files (need to make sure this works for both in tree and out of tree locales) Example: /manifests/$CATEGORY_ID/manifest.json (this structure intentionally maps directly to the webapp.manifest structure) { "locales": { "en-US": { "name": "xfoo" }, .... } } The collections app will read the json file and add the .locales section to results stored in the datastore. The homescreen(s) will read the current locale and look up the correct naming based on the values set in the locales dictionary... I am trying to avoid the need for issuing many XHR requests to the manifests and then building the manifest from the results of those... This would be fairly slow and easily done later if for some reason we need to fetch manifest names from the locale files directly.

About this: https://bugzilla.mozilla.org/show_bug.cgi?id=1016245#c3 does the e.me server already have localized names for the collections? If so can we return them in the server request for collections?

(In reply to James Lal [:lightsofapollo] from comment #20) > About this: https://bugzilla.mozilla.org/show_bug.cgi?id=1016245#c3 does the > e.me server already have localized names for the collections? If so can we > return them in the server request for collections? sure. see https://github.com/mozilla-b2g/gaia/blob/master/apps/collection/js/suggestions.js#L34-L37

I am going to use a much simpler approach like we used in v1.4 but with a shared locale file rather then trying to use a (IMO better but more complicated) approach that works better for third-party homescreens using datastore.

Works well for me on the collections app and on the homescreen... this requires each new app which uses the collection datastore to also include the l10n ini file I added in shared. Needs an integration test.

Comment on attachment 8442668 [details] https://github.com/mozilla-b2g/gaia/pull/20730 please address comments on Github. Thanks

Comments addressed

Comment on attachment 8442668 [details] https://github.com/mozilla-b2g/gaia/pull/20730 I took a look and it appears everyone's comments are addressed. We also have a green gaia-try build, so I think we are good here. Thanks guys!

Landed: https://github.com/mozilla-b2g/gaia/commit/a74ed1e3f982633950c2f93bbb46e71be6399da6

Hmm, looks like we crossed paths with another merge, might just need to update unit tests... I'll take a look. https://tbpl.mozilla.org/php/getParsedLog.php?id=42094397&tree=B2g-Inbound Reverted. https://github.com/mozilla-b2g/gaia/commit/a28cc995f42dd03a4f831a0f44f3c732a9c0b041

New pull request. I added a single line to the test to include l10n.js as we now need that since crossing paths with a commit that added tests.

Conflicts from cross-merge resolved. Landed: https://github.com/mozilla-b2g/gaia/commit/ae83bfe08752493e276bd432056bedf8ac592c53

Comment on attachment 8443143 [details] Github pull request This is needed for the vertical homescreen.

2.0: https://github.com/mozilla-b2g/gaia/commit/c5dd47e3f9e18872961946735fdbc071a1656ac9

Can you verify this bug?

Long press on Home -> Add Smart collections, the list is displayed localized in Italian on my Keon (2.1, git commit 2014-06-20 734d8459). If I switch to English, I get the English descriptions. If I select one, I don't see it appearing on the home (maybe a different bug).

Hey Francesco - anything in logcat when you see that? Thanks! (A lot of pieces for smart collections are landing today, so it may be a bit premature to verify bugs against it)

Used Flod's Italian translations, I also got the list correctly localized. If I select one, it's correctly added to the Homescreen. Its name is correctly localized on the Homescreen as well. However, the name on the header once opened is wrong: Installed collection-categoryId-296 = Intorno a me I got "Intorno a me" on the homescreen, but "Vicino a Me" on the header. Opening a follow-up bug for that. Tried on Flame with Gaia 008b5a4d1be8cb8416543047a748681cc70ea193 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/46b6814727ba BuildID 20140619160205 Version 32.0a2 ro.build.version.incremental=eng.theo.20140613.174651 ro.build.date=vendredi 13 juin 2014, 17:47:02 (UTC-0700)

(In reply to Kevin Grandon :kgrandon from comment #35) > Hey Francesco - anything in logcat when you see that? Thanks! Something must have fixed it in the middle: flashed keon with the current tip of master, and it works. I can confirm the behavior described by Théo: icon's name is localized, but when I open it I get e.me's name, which is different.

Right - we may want to talk to the E.me guys about this. They actually wanted the server to be able to override local translations in certain cases - but it does make sense that the label should match up to the header.