Firefox OS
5 years ago
5 years ago


(Reporter: Evyatar 'Tron' Amitay (, Assigned: Evyatar 'Tron' Amitay (



Firefox Tracking Flags

(Not tracked)



(1 attachment)

Evme shortcuts (smart folders) aren't localized- appear in English for all languages
Created attachment 698653 [details]
Patch - redirect to github PR

In order to translate the smart folders, and leave the translation in moz hands, we basically switched to searching by "id" instead of "query". This way the translation can be whatever the carrier wants, while the search results will remain the same (by the ID).
Attachment #698653 - Flags: review?(crdlc)
Attachment #698653 - Flags: approval-gaia-master?(21)
furthermore, ask to somebody to review this pr related to l10n, for example, @Stas
The title says r=vingtetun but actually I am the reviewer :)
it was when you were on holiday :) changed back to you.
Flags: needinfo?(l10n)

Comment 5

5 years ago
I'm not fond of the numeric IDs, does that have to be that way?

Also, I'm unsure about the goal here. If providers are expected to change the queries into, how does it help to expose some set of that across all locales to l10n?
Flags: needinfo?(l10n)
The idea is that providers could decide which default queries will appear on start page.

We ( have our own translations, but after some product talks it was decided that the providers will need the option to translate on their own (if, for example, our translation of "Travel" isn't the same as the provider, or even moz, would like) to avoid coupling with our own translation.

We have another open task in which we will move the config for the default shortcuts into a new config file, and we will create and host an HTML page that will allow generation of said config file.

This way if a new provider wants to have X,Y,Z shortcuts- they (or the moz represent) will go to our wizard, check those shortcuts, and will download the config file to put into the phone.

Re the numeric IDs- we're talking about maybe hashing them, but for now we're going to stay with them. Just to ease your mind- they're external IDs, so there's no risk of them changing or anything.

Comment 7

5 years ago
Not sure I really get it, but I guess it's gonna be OK.

Re the IDs, I'm not so much concerned about them being numbers, but that they're not descriptive names. Optimally, you'd had a mapper object in your js code that looked something like

l10n_shortcuts = {

and use that to get descriptive IDs from l10n.

Hashing the numbers should make things only worse, rather don't.

Comment 8

5 years ago
Hey Axel,

We've built a tool that will allow whoever is deploying a phone to customize the pre-packaged "shortcuts".

As soon as the list is prepared, it can be downloaded and modified on the device.

Since texts are changeable, we're relying on the shortcut id and that's why we've built the l10n keys with it as texts might change and still refer to the same shortcut which will lead to potentially non-existing translations.

If it's acceptable we'd rather not add an additional mapping layer and keep the keys mapped to ids. Makes sense?
Attachment #698653 - Flags: review?(crdlc) → review+
updated PR - moved the packaged shortcuts to a different config file, which could then be easily replaced with the output from

Comment 10

5 years ago
numeric key IDs have allways posed problems in the past, semantic names give more context to the localizer, and thus reduce errors.

Also, tying strings to code artifacts creates problems when you want to give that code thing a new name. Quite generally happens at some point down the line in most cases in my experience.
Added the mapping of the IDs- so the l10n key is
and we map it internally to use the proper ID.

are there any other open issues left regarding this?

Comment 12

5 years ago
Comment on attachment 698653 [details]
Patch - redirect to github PR

Thanks, looks good to me, f+ from an l10n pov.
Attachment #698653 - Flags: feedback+
Attachment #698653 - Flags: approval-gaia-master?(21) → approval-gaia-master+
Verified fixed in 2013-02-04-12-36-26 pvt nightly b2g18 build
You need to log in before you can comment on or make changes to this bug.