[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enigma-devel] Russian localization
From: |
Ronald Lamprecht |
Subject: |
Re: [Enigma-devel] Russian localization |
Date: |
Sat, 22 Jul 2006 00:22:20 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.7 (Windows/20050923) |
Hi,
Tacvek wrote:
I switched most instances of I18N to gettext_noop when I introduced
the instant language chance a year ago.
The problem in the case above is not L10N (the insertion of the
localized string) but the I18N part (the extraction of translatable
strings and generation of enigma.pot). As the string values for
'Target' do not exist in C++ gettext cannot extract them. They derive
from the XML level element "info/modes" and are "runtime" strings from
the aspect of gettext.
I did not cover these strings with the general I18N workaround for
levels as they do not really fit in. A simple workaround would be to
insert the known string-values anywhere in the C++ part without any
usage, just to let gettext find them. I just did not decide which way
is the best one - no unsolvable problem.
I know that bison does something similar by including the strings
in an "#if 0" block. Not very clean, and they don't even bother to use
gettext_noop.
Did you look at the po/level_18n.cc that I generate on extraction of
I18N strings from the levels:
[...]
//level# level: "Toreador"
//author# author: "Ronald Lamprecht" email "address@hidden"
//de# use: "Torero"
gettext("Toreador")
[...]
not really C++ - but neither me nor gettext does bother.
The few strings have just to be inserted anywhere - the "#if 0" is a
possible solution.
But something similar could work, especially as all possible values are
known ahead of time.
The cleaner solution would be to extract the possible values from the
XML schema,
but that would be slightly harder.
Of course that would require having the Schema limit the possible values
for that attribute, but that seems resonable.
It would also require a means to extract the values, but I suspect XSLT
can be used for that.
Unnecessary restriction and much too much work.
Either that, or if the code will ever read this attribute and use it in
some fashion, such asinternally triggering
the move based scorring system, then that seems like a fair place to use
N_(). Sure it would look
out of place, but it would guarentee that the strings are included in
the po template file.
The line creating the label should be changed to:
version.add(new Label(_(aLevel->getScoreTarget().c_str()), HALIGN_LEFT));
It is probably safe to make that change right now anyway, as the entries
wold be missing
the the po files, making it effectively a no-op.
I will add the changes prior the next pot update.
BTW (@Tacvek) I could not find the samples of the undocumented
"TRANSLATORS:" feature or any comments in the GNU Coding Standards.
Did you test it with C++? What is the syntax?
No I did not test it with C++, but I know it does work with C.
I just realized why it is not documented. It is not actually a part
of gettext, but simply a part of the default po/Makefile.in.in
Looking at the man page of xgettext will show that it has this option:
-c, --add-comments[=TAG]
place comment block with TAG (or those preceding keyword
lines)
in output file
and the default Makefile.in.in has
$(XGETTEXT) --default-domain=$(DOMAIN) --directory=$(top_srcdir) \
> --add-comments=TRANSLATORS: $(XGETTEXT_OPTIONS) \
[truncated]
So it should work in Enigma even in c++ code.
Thanks - it works seamlessly. I will use it to give the translators some
hints.
- Ronald
- Re: [Enigma-devel] Russian Localization, (continued)