Re: new localization framework - comments

Ricardo Palomares Mart=ED=ADnez wrote:
> Robert Kaiser escribi=F3:
>> [Posting this to multiple relevant newsgroups, followups to
>> mozilla.dev.i18n, which is very low-traffic, so don't hesitate to
>> subscribe to it if you're interested in this topic]
>>
>>
>> A few months ago, Axel Hecht from MoCo has worked on an idea for a new
>> localization framework that could be used for Mozilla2, but also for web
>> sites and other software.
>> (...)
>> I think we never collected the real issues people were seeing with his
>> proposals, so we should start collecting feedback, problems people are
>> seeing, and good points about it here.
>> (...)
>> Please post your (positive and negative) impressions about that
>> framework here in this thread, I hope we can get the discussion going on
>> this again and hopefully arrive at a usable spec and implementation
>> following that discussion.
> =

> Regarding the topic, as some of you know, I'm working in what
> should be the replacement for MozillaTranslator. It is still (I think)
> far from reaching a useful status, but I've thought a bit on how to
> fit L20n in its datamodel. Without entering in details I see a number
> of /challenges/ in L20n architecture; maybe not challenges, but points
> to consider.

Would you mind doing a post in .l10n about what that tool is supposed to =

do feature-wise and how it compares to stuff that's out there? We have a =

few independent projects running, and it seems to be costly to not =

design those tools in the open more aggressively.

> For a start, L20n is designed so localizers can add L10n objects and
> extend existing ones in en-US. L10n objects must be named, and a clear
> policy should exist so nobody can create a name that later conflicts
> with a new en-US L10n object. I've thought about forcing to add the
> locale code as a prefix for localizer added objects. It may be as
> simple as that, but it should written somewhere, so every ab-CD locale
> other than en-US respect it, and so developers don't add L10n objects
> starting with any kind of "ab-CD." prefix.

Actually, l20n is not designed for localizers to add objects, but to add =

properties on objects.

There might still be a chance for conflict, but I think it should be =

low. We should really not overload the individual objects too much, and =

just handle edge cases there. This isn't too obvious from the examples I =

did, of course, because they're all dealing with edge cases :-)

> I may be wrong, but I see L20n as something potentially complex to
> handle files by hand, and if tools are expected to grow around it,
> some adjustments should be taken into account to make those tools more
> useful. I keep missing UI context information, which would enable
> tools to help with non-conflicting accesskey assignments, and I'd like
> to review comments oriented to warn localizers.

Accesskeys are hard. Mostly because in our applications, the context =

isn't finite, damn extensions and overlays.
I'm not sure if there's a good way to solve this, let alone with =

non-Mozilla target applications in mind.

Marking this up in the l10n source has the down-side of actually =

requiring that that is bugfree, too. Like, how would the UI coder know =

which accesskey contexts are already in use, and find a unique one. That =

sounds like pushing the problem somewhere where it might not be solved =

as well.

> On the other hand, AFAIK there is still a long run (1 year at the very
> least?) to see something running on Mozilla 2, and therefore we should
> be plenty of time to implement tools. Am I wrong?

I think there should be plenty of time to improve on tools, yes.

Sorry for the lag.

Axel