[OpenLayers-Dev] Personal 2.6 Goals

[Attila Csipa]

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.