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

On 14/01/16 23:10, Bobby Holley wrote:
> 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 fails often, and I don't think it's OK to have jankier experience 
for localized UI.

Also, jankier UI may or may not be an option, given that chrome registry 
doesn't actually give us any fallback paths right now.

There's a lot of detail, a discussion apart from "rip out and replace" 
involves diving in to chrome registry, string bundles, and expat for DTD 
handling

Axel