« Return to Thread: new localization framework - comments
Re: new localization framework - comments
by Axel Hecht
::
Rate this Message:
Ricardo Palomares Martínez wrote:
> 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
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
> 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
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
« Return to Thread: new localization framework - comments
| Free embeddable forum powered by Nabble | Forum Help |
