Closed Bug 802383 Opened 12 years ago Closed 12 years ago

[Settings] Dynamically build the list of avaliable locales

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect, P1)

x86_64
Linux
defect

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
blocking-basecamp +

People

(Reporter: stas, Assigned: kaze)

References

Details

(Keywords: l12y)

Attachments

(1 file)

We shouldn't hardcode the list of available locales in settings/index.html.  This list could be:

- built dynamically on runtime,
- filtered dynamically on runtime,
- built on build time via some Makefile/mozharness magic.
Kaze, any thoughts on this?  I'd like to start the discussion about localized builds with releng and I feel that this is blocking us slightly.
We'll need this to properly build localized B2G, both for testing and production.  Requesting blocking-basecamp.

We want to be able to configure which locales are enabled in any given build (single- or multilocale) on the releng side via an all-locales file and buildbot configs.  This ensures scalability for v1 and later and will allow us to build localized testing builds.
blocking-basecamp: --- → ?
We can manage this with hardcoding for V1
blocking-basecamp: ? → -
Component: Gaia → Gaia::Settings
Now that bug 805781 changed the location of languages.json to shared/resource, it would be great to use it to dynamically construct the list of available locales from it.

It will make it significantly easier to do multilocale repacks.  See bug 766962 and its dependencies.
Depends on: 805781
I agree with Staś, it’s a trivial fix and it would be much easier to handle the localization.
Keywords: l12y
(In reply to dscravaglieri from comment #3)
> We can manage this with hardcoding for V1

I don't agree with this statement.  I believe that we should abstract our build system from the code.  Having a single central location to configure available locales is the way to go.  It will allow us to meet future requirements for shipped locales with no effort on the infrastructure side.  Re-nominating.
blocking-basecamp: - → ?
(In reply to Staś Małolepszy :stas from comment #6)
> (In reply to dscravaglieri from comment #3)
> > We can manage this with hardcoding for V1
> 
> I don't agree with this statement.  I believe that we should abstract our
> build system from the code.  Having a single central location to configure
> available locales is the way to go.  It will allow us to meet future
> requirements for shipped locales with no effort on the infrastructure side. 
> Re-nominating.

100% agree. We require at least two different l10n builds (dev ones, with 6 or so languages and localizer ones with 50+) so this isn't even a theoretical need.
Priority: -- → P1
Assignee: nobody → kaze
blocking-basecamp: ? → +
Attached file patch proposal
Attachment #684523 - Flags: review?(ehung)
Blocks: 812829
Comment on attachment 684523 [details]
patch proposal

r=me, thanks!
Attachment #684523 - Flags: review?(ehung) → review+
https://github.com/mozilla-b2g/gaia/commit/4bb84cb50c37d672e777d7b23f16c5bb217983ea
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: