[OSGeo-Discuss] Localization issues

[Markus Neteler]

Hi Jeroen, all,

in the GRASS development, we are facing essentially the same problem.
We have some translation efforts ongoing:

http://grass.itc.it/grass62/i18n.php#statistics
http://grass.itc.it/devel/i18n.php#statistics

but no Web based translation system. I was suggesting to OSGeo
last year, to establish a centralized system for all projects but that
times our infrastructure wasn't ready. In 2007, this might be easier.
I found
 http://www.dotmon.com/kartouche/
there might be more.

There was a problem with Launchpad: from their Web pages, Launchpad
claimed to take the copyright of the translated messages which is
not acceptable by the GRASS team. I was discussing with someone
from Launchpad, the person told me that this wasn't the case but
I didn't manage to make them a clear statement on their pages last
year:
  http://grass.itc.it/pipermail/translations/2006-June/000214.html
  http://grass.itc.it/pipermail/translations/2006-December/000246.html

I just checked now, it seems that something has happened:
 https://translations.launchpad.net/legal
But " ... In addition, the translator grants to Canonical Ltd the right
        to publish the translation and use the translation in other
        software packages under their license."

I am not sure if this is GPL compliant (GRASS is GPL). In any case,
I recommend to study their license carefully.

So, maybe we can push for an OSGeo infrastructure.

Best
Markus


PS: I guess my mail to geonetwork-devel gets trapped...

On 7/17/07, Jeroen Ticheler <Jeroen.Ticheler at fao.org> wrote:
> Hi all,
> In GeoNetwork opensource we deal with localization in a pretty
> trivial manner. We have XML documents that contain all strings we
> use. The element names in the string files are common across
> languages while the content in the elements are localized. For example:
>
> English:
>
> <strings>
>         <about>About</about>
>         <abstract>Abstract</abstract>
>         <accept>Accept</accept>
>         <add>add</add>
>         <addNewMetadata>Add new metadata</addNewMetadata>
> </strings>
>
> Arabic:
>
> <strings>
>         <about>عن البرنامج</about>
>         <abstract>مقدمة</abstract>
>         <accept>قبول</accept>
>         <add>إضافة</add>
>         <addNewMetadata>بيانات أساسية Metadata جديدة</
> addNewMetadata>
> </strings>
>
> etc..
>
> The content in the XML elements can also be HTML or contain
> attributes etc...
> Depending on the language selected, a different language file is used.
>
> The problem:
> With the expanding number of languages it becomes more problematic to
> keep all language files synchronized. It also is not trivial what
> strings have become obsolete, causing people to translate text that
> actually is not used anymore.
>
> The solution:
> Well, this is where we can use some ideas :-)
> - I've been looking at gettext format, noting that also Open Office
> uses that format with encoded XML content. A system like Launchpad's
> Translations ( https://translations.launchpad.net/ ) could than be
> used. We might need something to extract the strings from our XSLT
> and also to build the string files in XML format from the po files.
> - A custom web based database application could be used (build!?
> something existing!?) to store an identifier and than all different
> translations for the default string. This could provide feedback on
> if a string is deprecated and what the status of a translation is. It
> would probably also need some export mechanism to generate the static
> language files.
>
> There are probably other ways. i am curious to hear people's
> experiences and possible directions toward good solutions.
>
> Looking forward to useful suggestions,
> Ciao,
> Jeroen
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss