JOSM Translations

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

JOSM Translations

Marcin Floryan-3
Hi!

Recently someone on the list asked why JOSM is localised using plugins.
Since I work on JOSM translation a bit myself it made me think about
this particular approach and it seems like there might be some problems
with the current approach.

First and foremost the current approach effectively make it impossible
to release JOSM with complete and stable translation since there is no
relation between the JOSM code source code and the language plugins.
Potentially there could be JOSM bundle with the lang-* plugins included
but it would still not be accurate. On the other hand, if the lang-*
plugins get tied with JOSM core then creating translations for plugins
becomes questionable. And finally I recently noticed that OpenStreetBugs
plugin decided to take its own localisation approach - by including the
translation with the plugin itself.

Perhaps this is a good moment to consider whether some refactoring of
translations could be carried out to tidy things up.

I wonder what would people think about:
* Migrating JOSM core translations to JOSM core and out of the plugin so
  the core can be localised consistently and released with good
  translations. This would also eliminate problem with some messages
  that are currently non-translatable (before plugin is loaded)
  Perhaps launchpad could be use to maintain translations and then
  someone could maintain periodically updating the core.
* Keeping the lang-* plugins to hold translations for plugins that
  change more often.

Just a thought.

Regards,
M.
--
Marcin Floryan
http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Henrik Niehaus
From my point of view, the idea, to remove the i18n plugins and move the
i18n to the core is good. It makes things easier, if you just have to
put a language file into the jar or anywhere in a directory. The
translation of the core and the translation of the plugins should be
decoupled. That's why I put the i18n of the OpenStreetBugs plugin into
the plugin jar and didn't use the (for java) unusual gettext mechanism.
But there could be a way, how plugins register there i18n, if the core
needs access to it.

Resumee:
- no i18n plugins
- core i18n in the core
- plugin i18n in the plugins (maybe register at the core)

Marcin Floryan schrieb:

> Hi!
>
> Recently someone on the list asked why JOSM is localised using plugins.
> Since I work on JOSM translation a bit myself it made me think about
> this particular approach and it seems like there might be some problems
> with the current approach.
>
> First and foremost the current approach effectively make it impossible
> to release JOSM with complete and stable translation since there is no
> relation between the JOSM code source code and the language plugins.
> Potentially there could be JOSM bundle with the lang-* plugins included
> but it would still not be accurate. On the other hand, if the lang-*
> plugins get tied with JOSM core then creating translations for plugins
> becomes questionable. And finally I recently noticed that OpenStreetBugs
> plugin decided to take its own localisation approach - by including the
> translation with the plugin itself.
>
> Perhaps this is a good moment to consider whether some refactoring of
> translations could be carried out to tidy things up.
>
> I wonder what would people think about:
> * Migrating JOSM core translations to JOSM core and out of the plugin so
>   the core can be localised consistently and released with good
>   translations. This would also eliminate problem with some messages
>   that are currently non-translatable (before plugin is loaded)
>   Perhaps launchpad could be use to maintain translations and then
>   someone could maintain periodically updating the core.
> * Keeping the lang-* plugins to hold translations for plugins that
>   change more often.
>
> Just a thought.
>
> Regards,
> M.
> --
> Marcin Floryan
> http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> josm-dev mailing list
> [hidden email]
> http://lists.openstreetmap.org/listinfo/josm-dev


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Dirk Stöcker
On Tue, 21 Oct 2008, Henrik Niehaus wrote:

Please fix you quoting style. Top-quoting is not the best idea and
starting your own text with a quoting sign is also not so good. Thanks.

> From my point of view, the idea, to remove the i18n plugins and move the
> i18n to the core is good. It makes things easier, if you just have to
> put a language file into the jar or anywhere in a directory. The

Whereas I agree, that having the translations directly in the JOSM core to
make usage easier I disagree at some other points.

> translation of the core and the translation of the plugins should be
> decoupled. That's why I put the i18n of the OpenStreetBugs plugin into
> the plugin jar and didn't use the (for java) unusual gettext mechanism.

This has already been discussed. Gettext is an established system for
translations whereas the Java way has a lot of drawbacks.

Making a different approach for OpenStreetBugs plugin is nothing I
consider useful. Altogether this also means that the JOSM translators wont
translate the OpenStreetBugs plugin.

> But there could be a way, how plugins register there i18n, if the core
> needs access to it.

Why should the core require access to translation of plugins?

> Resumee:
> - no i18n plugins
> - core i18n in the core
> - plugin i18n in the plugins (maybe register at the core)

The management overhead to separate the plugin and core translations is
nothing I would accept.

What I would accept is moving the translations as they are now into the
core and abandon the language plugins. That means JOSM core would include
translations of plugins which may not be loaded, but that is a minor issue
in my eyes.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Marcin Floryan-3
On Wed, Oct 22, 2008 at 08:25:29AM +0200, Dirk Stöcker wrote:

> > translation of the core and the translation of the plugins should be
> > decoupled. That's why I put the i18n of the OpenStreetBugs plugin into
> > the plugin jar and didn't use the (for java) unusual gettext mechanism.
>
> This has already been discussed. Gettext is an established system for
> translations whereas the Java way has a lot of drawbacks.

I do agree - gettext approach is better not least because it provides
better tools for translators.

> The management overhead to separate the plugin and core translations is
> nothing I would accept.

Even if this meant just two translations - one for core and one for all
plugins? I can see where this gets more complicated but than plugins
change much more frequently than core does.
 
> What I would accept is moving the translations as they are now into the
> core and abandon the language plugins. That means JOSM core would include
> translations of plugins which may not be loaded, but that is a minor issue
> in my eyes.

If this is a general consensus then is there anyone taking up this task?
I am willing to volunteer for this one.

Regards,
Marcin
--
Marcin Floryan
http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Dirk Stöcker
On Wed, 22 Oct 2008, Marcin Floryan wrote:

>> This has already been discussed. Gettext is an established system for
>> translations whereas the Java way has a lot of drawbacks.
>
> I do agree - gettext approach is better not least because it provides
> better tools for translators.

Not only that. It is also much better for programmer.

>> The management overhead to separate the plugin and core translations is
>> nothing I would accept.
>
> Even if this meant just two translations - one for core and one for all
> plugins? I can see where this gets more complicated but than plugins
> change much more frequently than core does.

That is not true. The text changes for plugins and core aren't so much
different.

And the main problem would be to have one translation file but separate
that afterwards into different plugin files. It is possible, but I would
avoid that.

>> What I would accept is moving the translations as they are now into the
>> core and abandon the language plugins. That means JOSM core would include
>> translations of plugins which may not be loaded, but that is a minor issue
>> in my eyes.
>
> If this is a general consensus then is there anyone taking up this task?
> I am willing to volunteer for this one.

When you create the infrastructure to have the translation stuff in main
core - Fine. Thought we also need a way to interlink the language plugin
SVN structure as it is now with the new system, as I would not like to
move translation into JOSM core SVN (restricted write access, you know).

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Marcin Floryan-3
On Wed, Oct 22, 2008 at 11:03:56AM +0200, Dirk Stöcker wrote:

> > If this is a general consensus then is there anyone taking up this task?
> > I am willing to volunteer for this one.
>
> When you create the infrastructure to have the translation stuff in main
> core - Fine. Thought we also need a way to interlink the language plugin
> SVN structure as it is now with the new system, as I would not like to
> move translation into JOSM core SVN (restricted write access, you know).

I have done and tested the changes listed below. The results is that
there is no longer need for any translation plugins and i18n is
integrated into josm-core. There is also an appropriate link between the
two SVN repositories.

The pending changes are:

1.) The plugins/lang directory is removed
(http://svn.openstreetmap.org/applications/editors/josm/plugins/lang)
2.) A new directory "i18n" is created
(http://svn.openstreetmap.org/applications/editors/josm/i18n)
3.) The new directory contains all .po files and necessary build scripts
4.) As a result of build in that directory a new .jar file is created
    and copied to the core/lib directory
(http://josm.openstreetmap.de/svn/trunk/lib/josm-translation.jar)
5.) The core build process is modified to include the new jar file
6.) The MainApplications.java is modified to init the I18n.i18n

This way people can keep maintaining the .po files in the current SVN
repository and easily build and test translations for JOSM but changes
to the core repository can be committed separately and distributed
independently.

Now translations will be shown appropriately to the users' default
locale and can still be overridden with the --language parameter. It
would be easy as well to add language selection to properties.

If people are happy with this approach I can commit the changes.

Regards,
--
Marcin Floryan
http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Dirk Stöcker
Hello,

>> When you create the infrastructure to have the translation stuff in main
>> core - Fine. Thought we also need a way to interlink the language plugin
>> SVN structure as it is now with the new system, as I would not like to
>> move translation into JOSM core SVN (restricted write access, you know).
>
> I have done and tested the changes listed below. The results is that
> there is no longer need for any translation plugins and i18n is
> integrated into josm-core. There is also an appropriate link between the
> two SVN repositories.
>
> The pending changes are:
>
> 1.) The plugins/lang directory is removed
> (http://svn.openstreetmap.org/applications/editors/josm/plugins/lang)
> 2.) A new directory "i18n" is created
> (http://svn.openstreetmap.org/applications/editors/josm/i18n)
> 3.) The new directory contains all .po files and necessary build scripts
> 4.) As a result of build in that directory a new .jar file is created
>    and copied to the core/lib directory
> (http://josm.openstreetmap.de/svn/trunk/lib/josm-translation.jar)
> 5.) The core build process is modified to include the new jar file
> 6.) The MainApplications.java is modified to init the I18n.i18n

Sounds good to me. Thought I do not know how automatic build will handle
that. Frederik?

> Now translations will be shown appropriately to the users' default
> locale and can still be overridden with the --language parameter. It
> would be easy as well to add language selection to properties.

An option in the JOSM configuration is required also. Having
much discusson on merkaartor mailinglist I'm pretty sure it is
required :-)

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Frederik Ramm
Hi,

Dirk Stöcker wrote:

>> 1.) The plugins/lang directory is removed
>> (http://svn.openstreetmap.org/applications/editors/josm/plugins/lang)
>> 2.) A new directory "i18n" is created
>> (http://svn.openstreetmap.org/applications/editors/josm/i18n)
>> 3.) The new directory contains all .po files and necessary build scripts
>> 4.) As a result of build in that directory a new .jar file is created
>>    and copied to the core/lib directory
>> (http://josm.openstreetmap.de/svn/trunk/lib/josm-translation.jar)
>> 5.) The core build process is modified to include the new jar file
>> 6.) The MainApplications.java is modified to init the I18n.i18n
>
> Sounds good to me. Thought I do not know how automatic build will handle
> that. Frederik?

Would have to be modified (since it does not use the ant build script).
But does this change not mean that in the future, everyone who wants to
translate something needs an account on JOSM SVN? Is that desirable?

> An option in the JOSM configuration is required also. Having much
> discusson on merkaartor mailinglist I'm pretty sure it is required :-)

True.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Marcin Floryan-3
On Tue, Oct 28, 2008 at 05:37:41PM +0100, Frederik Ramm wrote:

> >> 1.) The plugins/lang directory is removed
> >> (http://svn.openstreetmap.org/applications/editors/josm/plugins/lang)
> >> 2.) A new directory "i18n" is created
> >> (http://svn.openstreetmap.org/applications/editors/josm/i18n)
> >> 3.) The new directory contains all .po files and necessary build scripts
> >> 4.) As a result of build in that directory a new .jar file is created
> >>    and copied to the core/lib directory
> >> (http://josm.openstreetmap.de/svn/trunk/lib/josm-translation.jar)
> >> 5.) The core build process is modified to include the new jar file
> >> 6.) The MainApplications.java is modified to init the I18n.i18n
> >
> > Sounds good to me. Thought I do not know how automatic build will handle
> > that. Frederik?
>
> Would have to be modified (since it does not use the ant build script).
> But does this change not mean that in the future, everyone who wants to
> translate something needs an account on JOSM SVN? Is that desirable?
Not really. All the translation files are still held on the OSM SVN so
people who want to contribute with translations can work there. Also,
since adding new languages now would only require the new .po file to be
added (and not the plugin files) it will be easier to take advantage of
launchpad translations (with someone committing the changes from lp to
svn). An account on JOSM SVN would only be required to change the
translation lib bundled with JOSM. So a small admin task that I presume
could easily be carried out by people who already have access.
 
> > An option in the JOSM configuration is required also. Having much
> > discusson on merkaartor mailinglist I'm pretty sure it is required :-)
>
> True.

OK. I thought so. Will add one.

--
Marcin Floryan
http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Dirk Stöcker
In reply to this post by Frederik Ramm
On Tue, 28 Oct 2008, Frederik Ramm wrote:

>> Sounds good to me. Thought I do not know how automatic build will handle
>> that. Frederik?
>
> Would have to be modified (since it does not use the ant build script).

Well. Would be fine to have the autobuild always used the most current
translations and thus updates the compiled translations before building
josm).

> But does this change not mean that in the future, everyone who wants to
> translate something needs an account on JOSM SVN? Is that desirable?

No. That's why we left the translations in OSM-SVN.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Lars Kruse
In reply to this post by Frederik Ramm
Hi,


Frederik Ramm <frederik@...> writes:

> But does this change not mean that in the future, everyone who wants to
> translate something needs an account on JOSM SVN? Is that desirable?

This could be either solved by using launchpad (as mentioned before) or by using
a pootle[1] server.

Pootle is a translation web interface similar to launchpad. Some advantages are:

1) automatic synchronization with a subversion repository (instead of manual
down/uploads and update/commit in launchpad)
2) various permission levels (suggest, review, translate, commit, ...)
3) it is free software

If anyone would like to test pootle for the josm translations, then I would
volunteer to set this up on a pootle server[2], that I am administrating.
This would not collide with manual svn uploads of pootle files - it would be
just an alternative path with a lower participation threshold for translators.

regards,
Lars


[1] http://translate.sourceforge.net/wiki/pootle
[2] http://translate.systemausfall.org



_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Stefan Baebler
A significant benefit of launchpad based translation is that many
other opensource applications are translated there, giving translators
a wide range of suggestions about how to translate strings.
Applications benefit a lot from consistent translations.

Downside of launchpad based translation is the need for an account in
launchpad, no automated SVN integration and forced BSD license [1] on
translated strings (lowest common denominator of varoius licenses).
I'd say these are minor inconveniences, but i might be wrong.

Stefan

[1] https://help.launchpad.net/Translations/LicensingFAQ


On Wed, Oct 29, 2008 at 12:55 PM, Lars Kruse <[hidden email]> wrote:

> Hi,
>
>
> Frederik Ramm <frederik@...> writes:
>
>> But does this change not mean that in the future, everyone who wants to
>> translate something needs an account on JOSM SVN? Is that desirable?
>
> This could be either solved by using launchpad (as mentioned before) or by using
> a pootle[1] server.
>
> Pootle is a translation web interface similar to launchpad. Some advantages are:
>
> 1) automatic synchronization with a subversion repository (instead of manual
> down/uploads and update/commit in launchpad)
> 2) various permission levels (suggest, review, translate, commit, ...)
> 3) it is free software
>
> If anyone would like to test pootle for the josm translations, then I would
> volunteer to set this up on a pootle server[2], that I am administrating.
> This would not collide with manual svn uploads of pootle files - it would be
> just an alternative path with a lower participation threshold for translators.
>
> regards,
> Lars
>
>
> [1] http://translate.sourceforge.net/wiki/pootle
> [2] http://translate.systemausfall.org
>
>
>
> _______________________________________________
> josm-dev mailing list
> [hidden email]
> http://lists.openstreetmap.org/listinfo/josm-dev
>

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Lars Kruse
Hi,

> A significant benefit of launchpad based translation is that many
> other opensource applications are translated there, giving translators
> a wide range of suggestions about how to translate strings.
> Applications benefit a lot from consistent translations.

if this is important for the josm translators, then I could create a
terminology database extracted from the po files of relevant projects.
See http://translate.sourceforge.net/wiki/pootle/terminology_matching


> Downside of launchpad based translation is the need for an account in
> launchpad, no automated SVN integration and forced BSD license [1] on
> translated strings (lowest common denominator of varoius licenses).
> I'd say these are minor inconveniences, but i might be wrong.

I guess, it just depends on the one, who would be willing to maintain the
translation entered via the web interface.
For launchpad this would involve regular manual synchronization - maybe once a
week.
For pootle it would be mainly poking at the specific language maintainers do
review translations and submit them (via the web interface). The committing
could also be done automatically. Then language maintainers would just need to
review the committed changes and revert them, if necessary.


There seem to be three options from my point of view:

A) would someone volunteer to maintain the launchpad translations?
B) Should we just try to see, if the submissions via the automated process of
   pootle suit the quality standards of the current translators?
C) We just keep the current state of translations being submitted via svn.

regards,
Lars

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Marcin Floryan-3
Lars Kruse wrote:

>> A significant benefit of launchpad based translation is that many
>> other opensource applications are translated there, giving translators
>> a wide range of suggestions about how to translate strings.
>> Applications benefit a lot from consistent translations.
>
> if this is important for the josm translators, then I could create a
> terminology database extracted from the po files of relevant projects.
> See http://translate.sourceforge.net/wiki/pootle/terminology_matching

I think the problem with this approach would be that launchpad already
references all projects that are translated there - both current and
future - it would seem an overhead to extract it manually. Just think of
what kind of size we would be talking here...

>> Downside of launchpad based translation is the need for an account in
>> launchpad, no automated SVN integration and forced BSD license [1] on
>> translated strings (lowest common denominator of varoius licenses).
>> I'd say these are minor inconveniences, but i might be wrong.
>
> I guess, it just depends on the one, who would be willing to maintain the
> translation entered via the web interface.
> For launchpad this would involve regular manual synchronization - maybe once a
> week.

Perhaps launchpad would be willing to extend their functionality and
allow for some kind of automation - just a thought but perhaps worth
suggesting.

> There seem to be three options from my point of view:

> A) would someone volunteer to maintain the launchpad translations?

Since I have already messed up with the translations in the first place
I think I can spare some time and look after this aspect. Obviously the
key to success then would be to make sure that everyone uses launchpad
and only launchpad. Fortunately it provides for both - translations
on-line and working with .po files (which many translators prefer). Also
it keeps track of who changed what.

> B) Should we just try to see, if the submissions via the automated process of
>    pootle suit the quality standards of the current translators?

I think my problem with this approach is the inability to work with .po
files directly. Way too often I work on translations when I am on the
train or the like and have no Internet access.

> C) We just keep the current state of translations being submitted via svn.

Perhaps this is the least favourable but will always exist as a 'fallback'

Kind regards,
Marcin Floryan

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Lars Kruse
In reply to this post by Marcin Floryan-3
Hi,

>>> A significant benefit of launchpad based translation is that many
>>> other opensource applications are translated there, giving translators
>>> a wide range of suggestions about how to translate strings.
>>> Applications benefit a lot from consistent translations.
>>
>> if this is important for the josm translators, then I could create a
>> terminology database extracted from the po files of relevant projects.
>> See http://translate.sourceforge.net/wiki/pootle/terminology_matching
>
>I think the problem with this approach would be that launchpad already
>references all projects that are translated there - both current and
>future - it would seem an overhead to extract it manually. Just think of
>what kind of size we would be talking here...

According to the expected benefit of a terminology database, it does not really sound worthwhile to me, to use a huge amount of translation to fill it.
But you are right: regarding the terminology, launchpad has an advantage over something like pootle.


>>> Downside of launchpad based translation is the need for an account in
>>> launchpad, no automated SVN integration and forced BSD license [1] on
>>> translated strings (lowest common denominator of varoius licenses).
>>> I'd say these are minor inconveniences, but i might be wrong.
>>
>> I guess, it just depends on the one, who would be willing to maintain the
>> translation entered via the web interface.
>> For launchpad this would involve regular manual synchronization - maybe once
>a
>> week.
>
>Perhaps launchpad would be willing to extend their functionality and
>allow for some kind of automation - just a thought but perhaps worth
>suggesting.

These issues have been raised quite a long time ago (e.g. 2006) by the KDE translation team:
http://wiki.kde.org/tiki-index.php?page=KDERosettaCollaboration
Additionally there is a bug filed for this issue (no replies, yet):
https://bugs.launchpad.net/rosetta/+bug/197891

Vaguely, this goal is on launchpad's roadmap - at least in connection with launchpad's bazaar repositories:
https://launchpad.net/launchpad-bazaar

Due to Rosetta's (the name of launchpad's translation web interface) focus on Ubuntu package translations, the missing synchronization with external upstream is a big issue for many projects. But it was not addressed within the last years, so I doubt, that this will change soon.


>> There seem to be three options from my point of view:
>
>> A) would someone volunteer to maintain the launchpad translations?
>
>Since I have already messed up with the translations in the first place
>I think I can spare some time and look after this aspect. Obviously the
>key to success then would be to make sure that everyone uses launchpad
>and only launchpad. Fortunately it provides for both - translations
>on-line and working with .po files (which many translators prefer). Also
>it keeps track of who changed what.

good.


>> B) Should we just try to see, if the submissions via the automated process
>of
>>    pootle suit the quality standards of the current translators?
>
>I think my problem with this approach is the inability to work with .po
>files directly. Way too often I work on translations when I am on the
>train or the like and have no Internet access.

Pootle can synchronize its translations with the upstream (subversion) repository in both directions. Thus you can still continue to use your favorite svn client to work on your translations offline.
Additionally you can download and upload .po files via the pootle web interface.


>> C) We just keep the current state of translations being submitted via svn.
>
>Perhaps this is the least favourable but will always exist as a 'fallback'

agreed.

regards,
Lars

PS: I am neither an active translator of josm, nor an active developer. Please understand my remarks on this issue just as helpful clarifications for the people who are really involved in development. The decision is up to you, anyway :)

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Женя
First of all, thanks for the good news. I like the idea of localisations inside the core.
I can't tell, wether it's good or bad to store all the plug-in translations in the core, too - but if it doesn't affect the archive size too much, I can live with that. Plus it's easier to translate, after all.

About the Launchpad usage - I don't really think there is much use of the existing translation suggestions - those are limited to "File", "Tools" and "Save as..." :)
Plus, LP works really slow over HTTPS for me.

So, now - a bug report about the new built-in localisations:
JOSM rev1059 - it can't find the Russian translation.

jekader@jiku:~$ /usr/lib/jvm/java-6-sun-1.6.0.*/bin/java -jar josm-latest.jar
Unable to find translation for the locale: русский (Россия) reverting to English.
loading measurement
loading openstreetbugs
Trying to load locale ru for openstreetbugs
Couldn't load resource bundle for locale ru_RU
Trying to load locale en for openstreetbugs
Silent shortcut conflict: 'Open OpenStreetBugs' moved by 'system:open' to 'Ctrl+Shift+O'.
loading osmarender
loading utilsplugin
Silent shortcut conflict: 'auto:Simplify Way' moved by 'system:redo' to 'Ctrl+Shift+Y'.

PS

jekader@jiku:~$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=


Женя mailto:[hidden email]


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Stefan Baebler
2008/10/30 Женя <[hidden email]>:
> About the Launchpad usage - I don't really think there is much use of the existing translation suggestions - those are limited to "File", "Tools" and "Save as..." :)
> Plus, LP works really slow over HTTPS for me.
True, but when starting translating into a new language even these
speed up the translation considerably, getting the translator quicker
over these boring phrases. I guess importing just few other (old &
well translated) projects translations into pootle would do the trick.

Another benefit of launchpad is the exposure the project gets amongst
experienced translators looking for new projects to translate. JOSM is
featured on front page of https://translations.launchpad.net/

> So, now - a bug report about the new built-in localisations:
> JOSM rev1059 - it can't find the Russian translation.
See the thread "Resource bundle not found exception" on this list.

Stefan
_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Shaun MS McDonald

On 31 Oct 2008, at 07:05, Stefan Baebler wrote:

> 2008/10/30 Женя <[hidden email]>:
>> About the Launchpad usage - I don't really think there is much use  
>> of the existing translation suggestions - those are limited to  
>> "File", "Tools" and "Save as..." :)
>> Plus, LP works really slow over HTTPS for me.
> True, but when starting translating into a new language even these
> speed up the translation considerably, getting the translator quicker
> over these boring phrases. I guess importing just few other (old &
> well translated) projects translations into pootle would do the trick.
>
> Another benefit of launchpad is the exposure the project gets amongst
> experienced translators looking for new projects to translate. JOSM is
> featured on front page of https://translations.launchpad.net/

The interesting thing that I noticed at Launchpad is that the en_GB  
translation has German translations for some reason.
https://translations.launchpad.net/josm/trunk/+pots/keys/en_GB/+translate
Is this correct?

Shaun


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Женя
In reply to this post by Marcin Floryan-3
Hi again.
So, the changelog says:

>Changeset [1065] by stoecker
>language handling fixed

But I'm still unable to set Russian in JOSM #1065
Moreover, English is the only variant in the preferences list :(

>
jekader@jiku:~$ /usr/lib/jvm/java-6-sun-1.6.0.*/bin/java -jar josm-latest.jar
Unable to find translation for the locale: русский (Россия) reverting to English.
Could not get presets icon presets/library.png
loading measurement
loading openstreetbugs
Trying to load locale ru for openstreetbugs
Couldn't load resource bundle for locale ru_RU
Trying to load locale en for openstreetbugs
Silent shortcut conflict: 'Open OpenStreetBugs' moved by 'system:open' to 'Ctrl+Shift+O'.
loading osmarender
loading utilsplugin
Silent shortcut conflict: 'auto:Simplify Way' moved by 'system:redo' to 'Ctrl+Shift+Y'.
>



Женя mailto:[hidden email]


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: JOSM Translations

Michel Marti-2
on 11/03/2008 01:28 PM Женя said the following:
> So, the changelog says:
>
>> Changeset [1065] by stoecker
>> language handling fixed
>
> But I'm still unable to set Russian in JOSM #1065
> Moreover, English is the only variant in the preferences list :(

"josm-latest.jar" (SVN r1065) still does not contain the translations:

 $ jar tf ./josm-latest.jar |grep Transl
 $

However, when building JOSM myself (using ant):

 $ jar tf dist/josm-custom.jar |grep Transl
 org/openstreetmap/josm/i18n/Translation_de$1.class
 org/openstreetmap/josm/i18n/Translation_de.class
 org/openstreetmap/josm/i18n/Translation_en_GB$1.class
 org/openstreetmap/josm/i18n/Translation_en_GB.class
 ...
 $

Seems like the nightly builds are not made using the same ANT infrastructure?!?


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
12