[josm-dev] Translators and Context driven translation

Dirk Stöcker openstreetmap at dstoecker.de
Mon Sep 21 11:21:20 BST 2009


On Sun, 20 Sep 2009, Ævar Arnfjörð Bjarmason wrote:

> On Sun, Sep 20, 2009 at 8:23 PM, Dirk Stöcker
> <openstreetmap at dstoecker.de> wrote:
>> as I still do not like to introduce context based translation for josm,
>> but on the other side we have conflicting strings in JOSM I now
>> implemented the middle way:
>>
>> When a string starts with ~ everything between ~ and the next : is
>> stripped from it when displayed. This allows to make strings context
>> based, whereas the text between ~ and : is the context.
>
> It's good to know that this is finally being supported. When I brought
> this up[1] in February you indicated that you were not interested in
> supporting any sort of context within translations. But with this
> feature applied I'll be able to translate JOSM without the UI being
> full of grammar errors. Yippie!

No, not "not at all". I only do not like the all-context based approach, 
as this increases the workload a lot with only little benefit. The problem 
based approach is fine for me.

> As I said[2] in that thread the gettext format has a native facility
> for specifying contexts since release 0.15. However it appears the
> Java implementation we're using doesn't support that. So either that
> has to be improved or we're going to have to use this hack, I'd prefer
> the hack to nothing at all.
>
> However a /standard/ hack is better than something ad-hoc JOSM comes
> up with. It looks like Launchpad already supports the hacky way KDE
> used to do this:

[...]

> So to get Launchpad support it looks like all you have to do is replace:
>
>    tr("~filter:E")
>
> with:
>
>    tr("_: filter\nE")

Changed it. Thanks for the hint.

Also added the gettext trc() and trnc() functions directly, which can be 
used inside of JOSM. This means the "_: xxx\n" is only required in presets 
and similar files.

> I don't know what native support of context actually means in
> Launchpad. Hopefully it means that if you have "_:Ctxt1\nBar" and
> "_:Ctxt1\nBar" and only translate the first string the second string
> will still show up translated. I.e. context will have been something
> optional the translator can add if he or she wants.

Launchpad has context support and detects this automatically.

>> Please report conflicts of translations, where this marking should be
>> used, so we can add the context to these.
>
> Can I get commit access so that I can fix these up when I see them?
> I've been fixing up i18n issues in the OpenStreetMap website whenever
> I see them and I'm a lot more likely to do it if I only have to open a
> .java file & edit it instead of filing a bug / submitting a patch /
> sending messages to the mailing list for each of those issues.

The mailinglist is not good for this. Adding patches in bugtracker is best 
solution (not for each text, but a bit collected). You can keep the fixes 
in SVN and only open (reopen) a trac when some texts have been collected.

For SVN access currently my rules are that some high quality patches must 
have been provided for some time. You do not yet qualify for this.

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


More information about the josm-dev mailing list