Translation issues

Content and general development discussion, including quest scripts and server code. TMW Classic is a project comprising the Legacy tmwAthena server & the designated improved engine server based on evolHercules.


Forum rules

This forum houses many years of development, tracing back to some of the earliest posts that exist on the board.

Its current use is for the continued development of the server and game it has always served: TMW Classic.

Post Reply
User avatar
Ces
Novice
Novice
Posts: 231
Joined: 19 Mar 2008, 22:46
Location: The hemisphere

Translation issues

Post by Ces »

First, I’m not sure where to put this... Perhaps a Translations subforum?

A. Notice: \r escape sequence in pt.po
pt:
msgmerge pt.po tmw.pot -o pt.new.po
..................... done.
pt.po:796: internationalized messages should not contain the `\r' escape sequence
pt.po:803: internationalized messages should not contain the `\r' escape sequence
pt.po:810: internationalized messages should not contain the `\r' escape sequence
pt.po:817: internationalized messages should not contain the `\r' escape sequence

Code: Select all

msgid "Attack:"
msgstr ""
"Copy text   \t\r\n"
"Ataque %+d"
I guess it’s just to remove that Copy part...

B. Question: Non valid C format strings in sv.po
rm -f sv.gmo && /usr/bin/msgfmt -c --statistics -o sv.gmo sv.po
sv.po:808: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In the directive number 1, the character 'T' is not a valid conversion specifier.
sv.po:813: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In the directive number 1, the character 'U' is not a valid conversion specifier.
/usr/bin/msgfmt: found 2 fatal errors
Not sure how to work around this, I wasn’t able to escape the percentage sign. “% A...”, “% E...” and “% R...” works, but for instance “% T” does not. Personally I would change the text from “% Accuracy: __” to “Accuracy: __ %”, then this problem is solved, but I’m still curious how to enter a percentage sign in the gettext msgs.

C. Strings not marked for translation
I’m willing to go through the source and enable gettext support for more strings (both the eAthena as the tmwserv client), if I’m ‘allowed’, a few questions:
  • tmwserv: is the server messages translateable as of now?
  • Error/log messages: the wiki says they shouldn’t be translated, personally I support translation of them; when English debug messages are needed they can be given with “LANG=C tmw” or some such, and having them in your own language as a user can help quite much
  • As of now some strings are translateable as “Label: %d” and others “Label:”, which should be used? (I guess the first way could be mandatory for some languages in some cases, even if I cannot come up with any real scenario in my mind just now.)
Winter greetings from someone who is busy with both life and death, but wishes for something else (translations, that is) to do for a day or two...
User avatar
Jaxad0127
Manasource
Manasource
Posts: 4209
Joined: 01 Nov 2007, 17:35
Location: Internet

Re: Translation issues

Post by Jaxad0127 »

Ces wrote:Error/log messages: the wiki says they shouldn’t be translated, personally I support translation of them; when English debug messages are needed they can be given with “LANG=C tmw” or some such, and having them in your own language as a user can help quite much
Anything shown to the user should be, but things put into the log shouldn't, so they we don't have to translate when debugging.
Image
User avatar
Crush
TMW Adviser
TMW Adviser
Posts: 8046
Joined: 25 Aug 2005, 16:08
Location: Germany

Re: Translation issues

Post by Crush »

Translating messages from the server (NPC dialogs or information messages) is a delicate topic.

Client- and server development are decoupled. A common server message can change without the client knowing resulting in the client not being able to translate it. Server messages can also be generated dynamically making it even harder to translate them client-sided.

The only feasible solution is to translate any messages server-sided. This means that the server has to know the language of the user. Not a big deal: You can transmit this information during the login sequence. But the way gettext works (getting the users language from an environment variable) is not feasible for an application which has to output text in different languages at the same time. We can maybe work around this by using different text domains for different languages or even engineer a completely homebrew solution.
but I’m still curious how to enter a percentage sign in the gettext msgs.
Did you try "\%"? "\" is usually the standard escape character.
  • former Manasource Programmer
  • former TMW Pixel artist
  • NOT a game master

Please do not send me any inquiries regarding player accounts on TMW.


You might have heard a certain rumor about me. This rumor is completely false. You might also have heard the other rumor about me. This rumor is 100% accurate.
User avatar
Ces
Novice
Novice
Posts: 231
Joined: 19 Mar 2008, 22:46
Location: The hemisphere

Re: Translation issues

Post by Ces »

Regarding logs, I have no clue at the moment what is passed to the console and what is written to file (by default), but I guess I’ll see in the source.

Regarding server messages, I guessed so. Hopefully we will have them translateable in the future.

Regarding the escape character, I already tried \% and %%. But after having RTFM for gettext, I replaced (in sv.po)

Code: Select all

#: src/gui/status.cpp:136
#, c-format
msgid "% Accuracy:"
msgstr "% Precision:"
with

Code: Select all

#: src/gui/status.cpp:136
#, no-c-format
msgid "% Accuracy:"
msgstr "% Precision:"
It seems to work, for now. But editing the po file like this is not ideal, I guess.

From the relevant part of the manual, how to fix this in the source:
Therefore the xgettext adds a special tag to those messages it thinks might be a format string. There is no absolute rule for this, only a heuristic. In the .po file the entry is marked using the c-format flag in the #, comment line (see PO Files).

The careful reader now might say that this again can cause problems. The heuristic might guess it wrong. This is true and therefore xgettext knows about a special kind of comment which lets the programmer take over the decision. If in the same line as or the immediately preceding line to the gettext keyword the xgettext program finds a comment containing the words xgettext:c-format, it will mark the string in any case with the c-format flag. This kind of comment should be used when xgettext does not recognize the string as a format string but it really is one and it should be tested. Please note that when the comment is in the same line as the gettext keyword, it must be before the string to be translated.

This situation happens quite often. The printf function is often called with strings which do not contain a format specifier. Of course one would normally use fputs but it does happen. In this case xgettext does not recognize this as a format string but what happens if the translation introduces a valid format specifier? The printf function will try to access one of the parameters but none exists because the original code does not pass any parameters.

xgettext of course could make a wrong decision the other way round, i.e. a string marked as a format string actually is not a format string. In this case the msgfmt might give too many warnings and would prevent translating the .po file. The method to prevent this wrong decision is similar to the one used above, only the comment to use must contain the string xgettext:no-c-format.
If no one else makes the change or protests, I’ll provide a patch with this change and a first batch of gettext strings in a few days time.

[edit] Patch available.
Post Reply