new localization framework - comments
Robert Kaiser
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.
The main goals of this framework are to overcome the problems and
limitations we know that the current Mozilla dtd/properties model and
the gettext/PO model have and provide not only a "best of both worlds"
but also solve problem that currently exist with both, such as gender
handling.
The current drafts of this are at <http://wiki.mozilla.org/L20n> on the
Mozilla wiki, along with features, designs, examples and problems.
Axel did a talk on FOSDEM about this in February, see also
<http://blog.mozilla.com/axel/2007/02/21/l20n-talk-slides-up/>, his
slides were interesting, but his examples and demos left many questions
open, confused some participants and reactions were split, esp. on the
actual file format.
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.
Also, a first try on an implementation (for and in PHP for trying out
how the logic works) unfortunately stalled because of licensing
questions, but I think we'd need an at least partially working
implementation to work out the real problems of the spec - once we even
arrive at a point where most people are content with a spec, actually.
We probably also need a first shot of a rough localization tool before
we really know this all works out, IMHO.
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.
Robert Kaiser
Ricardo Palomares Martínez
> [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.
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.
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.
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?
Ricardo.
Axel Hecht
> Robert Kaiser escribió:
>> [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
Ricardo Palomares Martinez
> Ricardo Palomares Martínez wrote:
>> 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.
Regarding extensions, I don't think anybody expects that a Mozilla
product full-loaded with extensions doesn't have accesskey conflicts;
even a lean, recently-installed one will have in some specific parts.
The thing here is to minimize the cases as much as possible.
> 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.
The problem exists indeed in en-US already. A developer adding a UI
element with an accesskey surely knows where is he placing it, and
should find easily the UI-context(s) applicable which, in turn, should
ease the election of the accesskey. Of course it will involve more
work for them, but if the UI-context can help to localizers by
providing automated checks, those same checks will be available also
for en-US.
>
> Sorry for the lag.
>
Ditto. :-)
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Ray Kiddy
> Axel Hecht escribió:
>> Ricardo Palomares Martínez wrote:
>>> 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.
>
>
> Regarding extensions, I don't think anybody expects that a Mozilla
> product full-loaded with extensions doesn't have accesskey conflicts;
> even a lean, recently-installed one will have in some specific parts.
> The thing here is to minimize the cases as much as possible.
>
>
>> I'm not sure if there's a good way to solve this, let alone with
>> non-Mozilla target applications in mind.
>>
I think there is a way to solve it. It requires a bit of investment,
though. Traditionally, access key collisions are too easy to just blame
on the last person to cause a conflict. This was certainly my experience
at Apple. The person most motivated to solve the problem is also under
the gun to just "get it fixed for right now".
There could be a component that keeps track of access key assignments.
For example, an extension could apply an access key, but do it through
the manager. The assignment would work only when the key was not assigned.
Actually, an extension developer would want to supply an array of keys
and the access key manager could assign the first one from the supplied
list that is not taken. This will allow an extension developer to make
use of access keys, as much as possible, without causing problems for
others. And then there be hooks for fall-back logic and such. Etc, etc.
So, I can design and write an XPCOM component to do this. Getting it
checked in would be another question. Getting anybody to use it would be
another, much harder, question. Does anyone have a suggestion for how to
proceed? Is there a good bug to use for this?
I do not mind creating the component, but I also do not have time to
spit into the wind.
By the way, lots of good I10N and L18N checking and testing could go
through this manager as well.
thanx - ray
Ricardo Palomares Martinez
> Ricardo Palomares Martinez wrote:
>> Axel Hecht escribió:
>>> I'm not sure if there's a good way to solve this, let alone with
>>> non-Mozilla target applications in mind.
>>>
>
> I think there is a way to solve it. It requires a bit of investment,
>
> There could be a component that keeps track of access key assignments.
> For example, an extension could apply an access key, but do it through
> the manager. The assignment would work only when the key was not assigned.
I'm not sure I'm getting you. Do you mean that the developer (or the
localizer, for that matter) won't be the one deciding the accesskey
while writing the code, but just let a component choose it at runtime
in a way that doesn't cause conflicts? Don't you think this will lead
to different accesskeys for each execution, or at least vary the
accesskey for a UI element depending of the installed extensions?
As a user, I'm pretty sure I wouldn't want the program to be
dinamically changing the accesskeys just because I've installed an
extension. Besides accessibility, accesskeys provide quick access to
options that aren't used so often to assign them a shortcut.
> Actually, an extension developer would want to supply an array of keys
> and the access key manager could assign the first one from the supplied
> list that is not taken. This will allow an extension developer to make
> use of access keys, as much as possible, without causing problems for
> others. And then there be hooks for fall-back logic and such. Etc, etc.
At first sight, I'd say that may actually involve more work. The
developer (I'm not restricting here to extension developers) would
pick their choice for every UI element, but after testing a nightly,
it could happen that the different keysets cooperate in a way that
makes some UI elements run out of "keys of choice", or make weird
assignments. The developer should re-think every keyset to get a
better assignment.
As I'm doing some changes to an old L10n tool, I also thought of
providing an automated accesskey assignment, but I discarded
inmediately because of reasons similar to the above explained.
> So, I can design and write an XPCOM component to do this. Getting it
> checked in would be another question. Getting anybody to use it would be
> another, much harder, question. Does anyone have a suggestion for how to
> proceed? Is there a good bug to use for this?
>
> I do not mind creating the component, but I also do not have time to
> spit into the wind.
I'd like to know Axel's opinion on this, as I may be a bit
short-sighed with these questions.
Ricardo
Axel Hecht
Trying to get my head into this one again.
I'm not sure that doing an array of accesskeys is going to be as stable
as we would like it to be. Like, this would end up depending on the
order in which overlays are loaded, right? Which might be a hash
thingie, thus you could change the order by just adding a new item, and
even though no conflict to be removed changed, the resolution could change.
Sounds like a bag of bees to me. Anyway, sounds to me like something
that should be discussed in a group with a wider audience, maybe m.d.t.xul?
Axel