<div>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. </div>
<div> </div>
<div>Please if you have comments on this email, make them here.</div>
<div> </div>
<div>Erik<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Attila Csipa</b> <<a href="mailto:plists@prometheus.org.yu">plists@prometheus.org.yu</a>><br>Date: Jan 15, 2008 10:33 AM
<br>Subject: Re: [OpenLayers-Dev] Personal 2.6 Goals<br>To: <a href="mailto:dev@openlayers.org">dev@openlayers.org</a><br><br></span>On Tuesday 15 January 2008 16:21:27 Mike Adair wrote:<br>> I think I have my sandbox fixed up and merged with trunk properly now so
<br>> I'll be preparing a patch for the I18n framework this week. There is<br>> some translation done, but not much and only with my rudimentary<br>> French. Support for other languages and translation can easily be added
<br>> after the fact.<br><br>I realize I'm a bit late to the partya and an OL newbie, but I'd give a couple<br>of suggestions as, on the long run, I'm interested in the<br>internationalization/localization of OpenLayers myself and have amassed, what
<br>I'd like to believe, a considerable amount of experience in the i18n/a11y<br>topic. If you think they have merit we could join forces but other comments<br>are welcome, too. In no particular order, these suggestions are:
<br><br>1. I'd stick to the format of functions people using translations are familiar<br>with. If it works like gettext, call it gettext.<br><br>2. Where there is gettext, ngettext should not be far off (I work mostly with
<br>languages that are particularly sensitive to this, but that's just me).<br><br>2. It's good to have locale sorted out right from the start. While people<br>might think ugly having to type 'en_US' instead of just 'en', it helps us who
<br>don't happen to be in the US, and we can always fallback if someone forgets<br>it. Aside from Canadians and UK people, a lot of Spanish and Portugese<br>speaking users can be made happy with that, Germans, etc, the list goes on :)
<br><br>3. Encoding ! While it's easy to make a decree and say we're all utf8, in many<br>many places it's not that simple (what if the page we're being<br>embedded/retrofitted in isn't in utf8?), so a strategy is to be determined,
<br>or adequate translation dictionaries established (en_US.UTF-8 and alike)<br><br>4. Maybe most important of all these - I think the dictinaries should NOT be<br>common, we really don't want them to apply to ALL components and have a lot
<br>of people editing these files simultaneously. A central dictionary is<br>attractive at first, but later turns out to be a nightmare (overlapping<br>strings, different meanings in different languages for something that might
<br>be called with just one word or the same expression in english - like the<br>word 'layer' for example). I'd suggest translations roughly on the level of<br>Classes, so each handler, control, etc would have it's dictionary which would
<br>be a lot clearer to maintain (who's responsible, or what should be translated<br>if the given class changes).<br><br>5. Use of external tools - some technologically similar projects already have<br>tools that allow conversion from industry standards - .po files, maybe xliff,
<br>etc (see f.e. the jala project). Being compatible with these makes it<br>possible for translator to use their favorite tools, which is important as<br>translation should be possible to do without almost any knowledge of how the
<br>code works or experience in programming in general. If it's just a couple<br>strings, there may be not a large difference, but there is no need to be<br>different just for the fun of it.<br><br>6. Numbers. In the geo-arena, we're dealing with a lot of numbers, esp
<br>coordinates, and the format of these unfortunately isn't even remotely the<br>same everywhere (separators, notations). It would mean really a lot<br>(professionally) if we could have a framework level solution for this.
<br><br><br>That would be it as a first run, feel free to comment. I don't want to push<br>implementation of any of my points above on anyone, I just want to draw some<br>comments out and perhaps help create some perspective as many of the
<br>mistakes/hurdles that projects usually go through when they decide to<br>internationalize are avoidable. I'm willing to contribute in code/time making<br>most of what I wrote above a reality, I just don't have the
<br>motivation/funding at the moment to justify making it a priority issue. Once<br>more, apologies if you think I'm jumping the gun here or am rehashing points<br>perhaps already raised in previous discussions I'm unaware of.
<br>_______________________________________________<br>Dev mailing list<br><a href="mailto:Dev@openlayers.org">Dev@openlayers.org</a><br><a href="http://openlayers.org/mailman/listinfo/dev">http://openlayers.org/mailman/listinfo/dev
</a><br> </div>