enigma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enigma-devel] Russian localization


From: Tacvek
Subject: Re: [Enigma-devel] Russian localization
Date: Wed, 19 Jul 2006 14:01:46 -0400


----- Original Message ----- From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>
Cc: <address@hidden>
Sent: Wednesday, July 19, 2006 2:44 AM
Subject: Re: [Enigma-devel] Russian localization


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.

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.

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.





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.

There are examples in the gettext manual, or in the source for GNU hello.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]