[OpenLayers-Dev] Translation / Internationalisation (was: Personal 2.6 Goals)

Erik Uzureau erik.uzureau at metacarta.com
Tue Jan 15 12:37:08 EST 2008


Thanks Atilla for this detailed email of suggestions. I'm moving it to its
own thread just so as to keep it separate from the 2.6 prep thread.

Please if you have comments on this email, make them here.

Erik

---------- Forwarded message ----------
From: Attila Csipa <plists at prometheus.org.yu>
Date: Jan 15, 2008 10:33 AM
Subject: Re: [OpenLayers-Dev] Personal 2.6 Goals
To: dev at openlayers.org

On Tuesday 15 January 2008 16:21:27 Mike Adair wrote:
> I think I have my sandbox fixed up and merged with trunk properly now so
> I'll be preparing a patch for the I18n framework this week.  There is
> some translation done, but not much and only with my rudimentary
> French.  Support for other languages and translation can easily be added
> after the fact.

I realize I'm a bit late to the partya and an OL newbie, but I'd give a
couple
of suggestions as, on the long run, I'm interested in the
internationalization/localization of OpenLayers myself and have amassed,
what
I'd like to believe, a considerable amount of experience in the i18n/a11y
topic. If you think they have merit we could join forces but other comments
are welcome, too. In no particular order, these suggestions are:

1. I'd stick to the format of functions people using translations are
familiar
with. If it works like gettext, call it gettext.

2. Where there is gettext, ngettext should not be far off (I work mostly
with
languages that are particularly sensitive to this, but that's just me).

2. It's good to have locale sorted out right from the start. While people
might think ugly having to type 'en_US' instead of just 'en', it helps us
who
don't happen to be in the US, and we can always fallback if someone forgets
it. Aside from Canadians and UK people, a lot of Spanish and Portugese
speaking users can be made happy with that, Germans, etc, the list goes on
:)

3. Encoding ! While it's easy to make a decree and say we're all utf8, in
many
many places it's not that simple (what if the page we're being
embedded/retrofitted in isn't in utf8?), so a strategy is to be determined,
or adequate translation dictionaries established (en_US.UTF-8 and alike)

4. Maybe most important of all these - I think the dictinaries should NOT be
common, we really don't want them to apply to ALL components and have a lot
of people editing these files simultaneously. A central dictionary is
attractive at first, but later turns out to be a nightmare (overlapping
strings, different meanings in different languages for something that might
be called with just one word or the same expression in english - like the
word 'layer' for example). I'd suggest translations roughly on the level of
Classes, so each handler, control, etc would have it's dictionary which
would
be a lot clearer to maintain (who's responsible, or what should be
translated
if the given class changes).

5. Use of external tools - some technologically similar projects already
have
tools that allow conversion from industry standards - .po files, maybe
xliff,
etc (see f.e. the jala project). Being compatible with these makes it
possible for translator to use their favorite tools, which is important as
translation should be possible to do without almost any knowledge of how the
code works or experience in programming in general. If it's just a couple
strings, there may be not a large difference, but there is no need to be
different just for the fun of it.

6. Numbers. In the geo-arena, we're dealing with a lot of numbers, esp
coordinates, and the format of these unfortunately isn't even remotely the
same everywhere (separators, notations). It would mean really a lot
(professionally) if we could have a framework level solution for this.


That would be it as a first run, feel free to comment. I don't want to push
implementation of any of my points above on anyone, I just want to draw some
comments out and perhaps help create some perspective as many of the
mistakes/hurdles that projects usually go through when they decide to
internationalize are avoidable. I'm willing to contribute in code/time
making
most of what I wrote above a reality, I just don't have the
motivation/funding at the moment to justify making it a priority issue. Once
more, apologies if you think I'm jumping the gun here or am rehashing points
perhaps already raised in previous discussions I'm unaware of.
_______________________________________________
Dev mailing list
Dev at openlayers.org
http://openlayers.org/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080115/f48e820c/attachment.html


More information about the Dev mailing list