On Sun, 20 Sep 2009, Ævar Arnfjörð Bjarmason wrote:
On Sun, Sep 20, 2009 at 8:23 PM, Dirk Stöcker
<[email protected]> 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)
_______________________________________________
josm-dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/josm-dev
