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

On 14/01/16 23:33, Bobby Holley wrote:
> On Thu, Jan 14, 2016 at 2:17 PM, Axel Hecht <[email protected]> wrote:
>
>> 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
>
>
> I admit to not knowing much about the subject here, but I'm having trouble
> reconciling "l10n is currently infallible" with "l10n fails often". Is the
> issue that the current failures manifest at build-time? If so, could we
> somehow preserve the ability to statically verify l10n correctness and turn
> we turn it into some kind of validator / test suite that we run on CI?
>

There's a context switch:

Getting a localized string from some arbitrary blob that's unrelated to 
the binary that you're running is fallible, and fails often.

Creating that blob of localized content shouldn't be.

This thread is about creating the blobs.

Separating the blobs is about making individual calls into 
nsIStringBundle.getString() fallible.

Axel

>
>> , and I don't think it's OK to have jankier experience for localized UI.
>>
>
> I was only proposing it in the case where this is an exceptional failure
> case that we do not expect to hit often if at all.
>
>
>
>>
>> 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
>>
>> _______________________________________________
>> dev-planning mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-planning
>>