« Return to Thread: new localization framework - comments
Re: new localization framework - comments
by Ricardo Palomares Martínez
::
Rate this Message:
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.
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.
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
> [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.
_______________________________________________
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 |
