[josm-dev] JOSM-Tested

Ævar Arnfjörð Bjarmason avarab at gmail.com
Sat Jun 12 00:13:44 BST 2010


On Fri, Jun 11, 2010 at 22:39, Frederik Ramm <frederik at remote.org> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>>
>> This wouldn't solve the issue of having 100% complete translations at
>> time of release. But it seems that for overall translation
>> completeness Translatewiki is working great for OSM. We both have
>> active OSM contributors, and an active general translation community
>> contributing.

Before I go any further I'd just like to point out that the above was
just a humble suggestion of the form "if you're interesetd, you can do
X, maybe".

I'm not saying JOSM should do anything in particular, I just wanted to
point out the option since we've had success with this approach for
the website and Potlatch.

> To be honest I'm not keen on having anything translated by members of a
> general translation community. There are many things which, I believe, need
> the OSM context to be translated properly.

FWIW JOSM is already available for translation by the larger
community. It's open to anyone with a Launchpad account, and if you go
into their statistics as a translator it'll be listed amongst
$very_large_number of programs that you might want to translate into
language X.

Using another translation service would potentially make it more
popular, but it wouldn't change that.

> I recently changed the E->D translation on launchpad for a number of OAuth
> related items. I don't remember what the problem was exactly but it was
> clear that the translator did not know anything about how OAuth works, but
> just chose context-free translations of the terms involved. This resulted in
> a very skewed overall picture. The person did have an OSM background but it
> seems no OAuth knowledge.
>
> I would expect many more problems of that caliber to show up if we let
> people without OSM exposure translate stuff. It may just about work for the
> web site (but even there I'm skeptical) but not for a sophisticated editor.

Most of the strings in the website are translatable without context by
someone not familiar with OSM. For every technical osm-specific error
message there are 10 nominatim strings, or some general message anyone
can translate.

Also, translators *love* having context strings. Most of the string in
Potlatch on Translatewiki have context strings, and our translations
are a lot better for it (see
http://www.gnu.org/software/gettext/manual/gettext.html#Bug-Report-Address
for the general idea).

> In my eyes, a *bad* (or half-good) translation is worse than no translation
> at all. If members of the JOSM or at least OSM community do not have the
> time to translate JOSM into Ancient Greek then I'd prefer not to have an
> Ancient Greek JOSM at all, rather than having an Ancient Greek JOSM which
> has been translated by Ancient Greek enthusiast who knew nothing of OSM.

I have to completely disagree there. Most people don't understand
English at the technical level required to make sense of a program
like JOSM. These are the people that benefit the most from translated
programs. Personally I just use everything in English even though I've
contributed a lot to translation infrastructure.

Having a bad translation v.s. no translation can be the difference
between being able to use the program and not using it at all.

Imagine using a UI in Klingon v.s. one in very bad machine translated
Engrish. It'd have to be pretty bad to not be more understandable than
the original.

> Unfortunately the statistics capture quantity, not quality.

Yeah, and neither of us has the language skills nor the time to do a
good review of Launchpad v.s. Translatewiki in this respect, so this
discussion is doomed to remain forever hypothetical.

I have a lot of confidence in the work of people that do things for
free because they're passionate about it. There's a lot of translation
geeks on both Translatewiki and Launchpad, generally they do a very
good job of translating unfamiliar programs given the constraints.




More information about the josm-dev mailing list