I18n problems

Hello.
I want to discuss some issues related to the development and translation.
I am a member of a team of translators for Russian language. At the present time it is the most translated language (more than 70% of the strings) and I want the Cataslysm DDA version 0.8 came out translated fully.

  1. When a developer makes a commit to the master branch .pot file gettext’a becomes outdated. However, the file lang/po/cataclysm-dda.pot is not updated. I want to ask the developers to run lang/update_pot.sh after the upgrade of master branch. It will support the translation to commit date.

  2. I want to create a github branch from which I will merge updates of Russian translation. It would be desirable that these updates were made. Is that possible?

  3. Sometimes source contain code, inconvenient to translator. I would like to change these lines without affecting functionality. It would be desirable that these changes were made. Is that possible?

Also I want to know: maybe it’s time to move Cataclysm-DDA on any build system? I can replace simple Makefile to automake or cmake. If interested, please contact me here or mail vnigtha at gmail or IRC: funnyHeretic on #cataclysm-dda.

Me too :slight_smile:

Yea we need to get better about that, I’m wondering if we can add a jenkins hook to catch this.

Absolutely, that’s the plan with translations. As translations are added, we’ll merge them into the main repository.

You’ll need to be more specific, I’m not sure what you mean.

We’ve put a lot of effort into making the Makefile work properly, we’re open to adding other build files, but outright replacing the Makefile is a hard sell for several reasons:

  1. Any replacement has to provide 100% of the functionality of the Makefile.
  2. Any replacement has to run on all our supported platforms. (linux, windows, and mac)
  3. cmake and autotools introduce additional build dependencies above what we currently have (the tools themselves), making the build process less accessable rather than more, which is a major goal.
  4. The core developers (including myself) don’t necessarally know how to work with autotools and cmake, which means we either have additional workload to learn them, or are at the mercy of whoever does know those sytems, which means we’re more likely to have things break.

Balanced against this, the current system does everything we need it to, what features are missing?

Autotools and cmake project files in addition to the current build system would be fine, but they need to be carefully setup to not overwrite the existing build files, which both of them do by default.

Yea we need to get better about that, I'm wondering if we can add a jenkins hook to catch this.
I dont' know what is jenkins hook, but i can do it. Once per day, for example. Or, betrer way, devlopers should do it. Simple workflow: 1. commit (big or small) to master branch. 2. someone or something run lang/update_pot.sh 3. commit changed cataclysm-dda.pot to master branch.
Absolutely, that's the plan with translations. As translations are added, we'll merge them into the main repository.
Good.
You'll need to be more specific, I'm not sure what you mean.
Here [u]simple[/u] example from gettext doc: [code] In C programs strings are often used within calls of functions from the `printf' family. The special thing about these format strings is that they can contain format specifiers introduced with `%'. Assume we have the code
 printf (gettext ("String `%s' has %d characters\n"), s, strlen (s));

A possible German translation for the above string might be:

 "%d Zeichen lang ist die Zeichenkette `%s'"

A C programmer, even if he cannot speak German, will recognize that
there is something wrong here. The order of the two format specifiers
is changed but of course the arguments in the `printf’ don’t have.
This will most probably lead to problems because now the length of the
string is regarded as the address.

To prevent errors at runtime caused by translations the msgfmt' tool can check statically whether the arguments in the original and the translation string match in type and number. If this is not the case and the-c’ option has been passed to msgfmt',msgfmt’ will give an
error and refuse to produce a MO file. Thus consequent use of `msgfmt
-c’ will catch the error, so that it cannot cause cause problems at
runtime.

If the word order in the above German translation would be correct one
would have to write

 "%2$d Zeichen lang ist die Zeichenkette `%1$s'"

The routines in `msgfmt’ know about this special notation.[/code]

Balanced against this, the current system does everything we need it to, what features are missing?

It’s about future. Project become bigger and more complicated. It is possible that(i hope not) in the future will need add more flexible build system, but it is harder to do than it is now. So, if you need to add build system, i can do it. If you don’t need than. It’s good.

As i understand, i can make branch on github and my(Russian) translations will be accepted. That’s good. Thank you.

Your understanding is correct yes.

About the word order issue, We’re working on cleaning up the format strings to make this kind of thing work properly, though it isn’t done yet. If you want to either report strings that have this problem or submit pull requests on github addressing them, that would be great.