Re: l10n-as-addon (Was: Getting a Tier-X for localized builds. X=1)

On Thu, Jan 14, 2016 at 2:00 PM, Axel Hecht <[email protected]> wrote:

> On 14/01/16 22:45, Mike Hommey wrote:
>
>> On Thu, Jan 14, 2016 at 01:36:36PM -0500, Chris AtLee wrote:
>>
>>> I'd very much like to ship language-agnostic builds and have strings
>>> delivered independently from the release process, as a system addon or
>>> somesuch. That would dramatically simplify our release process!
>>>
>>
>> Yes, using a system addon for locale would simplify a lot of things,
>> starting with repacks. And making en-US a locale like any other would
>> ensure that things work properlty with langpacks. There are technical
>> details to figure out to make that work if we want to go that path,
>> though (as in, within gecko, iirc there are a few thing that currently
>> don't work with langpacks)
>>
>> Mike
>>
>>
> Doing this is part of a rewrite of Firefox and Gecko, basically.
>
> That doesn't make it bad, but it makes it expensive.
>
> The current l10n infra makes l10n infallible. Separating l10n from the
> build means that l10n might fail, and if it fails, it needs to fall back to
> something (like en-US). Which is additional IO, and thus needs to be async.
> Which violates all gecko APIs.
>

How often does l10n fail? Is it acceptable to just do sync IO and settle
for a jankier experience in that fallback case?


>
> L10n.js/l20n.js in gaia land are way ahead of the curve, but we also
> rewrote a bunch of gaia to support runtime fallback and modern l10n apis.
>
> And then there's the UX question about how to do installers that actually
> offer language choice that's no worse than the web.
>
> 'cause if we do per-locale installers, we just do per-locale builds,
> there's no difference in wall clock time and complexity of the system.
>
> Let's make this part of the thread end here? It's all part of a different
> plan, and won't help us in a timeframe that's relevant to this thread.
>
> Axel
>
> _______________________________________________
> dev-planning mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-planning
>