From The Battle for Wesnoth Wiki
Revision as of 09:44, 12 January 2018 by Vasya (talk | contribs)

Note: As of April 4th, 2015, Wescamp appears to have been abandoned for about a year. It might be back soon, it might not. Someone with knowledge of the project should update this page.

This page is dedicated to describing how to translate user-made content with the help of the WesCamp-i18n project.

This project is hosted at GitHub and maintained by AI/AI0867. Add-ons are uploaded to git repositories and .po files of the content are created. The .po files are updated regularly and the stats can be found at http://gettext.wesnoth.org.

If you are someone who just wants to translate

Then, simply go to http://gettext.wesnoth.org, and download the .po file of your chosen add-on and language. Then read the information for translators on this page here to know whom to tell what you are working on, and where to submit your translations.

Preparing your add-on for WesCamp

In order for your add-on to be compatible with WesCamp’s translation tools, certain things must be done. This section describes what must be done and what should be done anyway.

Encoding and Filenames

Your files must be in UTF-8 (not whatever other encoding you might happen to be using/want to use, such as ISO-8859-15) and there must be no spaces in any of your add-on’s files’ names.

The textdomain declaration

First, your add-on must declare a textdomain. To do this, make sure something like the following is inside of your _main.cfg:


Note that to be compatible with WesCamp’s tools, the part of the textdomain after wesnoth- must match your add-on’s directory name. In this example, the add-on’s directory is Son_of_Haldric, thus we would get wesnoth-Son_of_Haldric.

The translations directory is where compiled translations would go.

The textdomain bindings

All files with translatable strings must be bound to your domain. See the example below:

  #textdomain wesnoth-Son_of_Haldric
      name= _ "Mu"

Note that you can reuse translations for strings in mainline domains by using multiple textdomain bindings or a gettext helper file (which will be explained later):

   # textdomain wesnoth-Son_of_Haldric
       name= _ "Mu"
           #textdomain wesnoth-units
           description= _ "sword"
       #textdomain wesnoth-Son_of_Haldric

Of course, if you use bindings for multiple textdomains, make sure the right parts of the file are bound to the right domains. Also, never try to use the mainline campaigns’ domains, for there is no guarantee that the mainline campaigns will be available on all setups. So, only use the core domains: wesnoth, wesnoth-editor, wesnoth-lib, wesnoth-help, wesnoth-test, and wesnoth-units.

Note that it is highly recommended that the first textdomain binding be on the first line of the file. Otherwise, odd stuff may happen.

The translatable strings

To mark a string as translatable, just put an underscore ( _ ) in front of the string you wish to be marked as translatable, like the example below:

   name= _ "Mu"

Note that there are certain things you should never do. For example, never mark an empty string as translatable, for wmlxgettext (the tool that extracts strings from WML) will abort upon detecting one. Therefore, what is seen below should never be done:

  name= _ ""

Also, never put macro arguments in a translatable string, for it will not work. The reason for this is that the preprocessor does its job before gettext, thus gettext will try to replace a string that does not exist. Therefore, what is shown below should not be done:

   name= _ "{TYPE} Mu"

To show why it will not work:

  #define UNIT_NAME TYPE
      name= _ "{TYPE} Mu"
  {UNIT_NAME ( _ "Sword")}
  {UNIT_NAME ( _ "Bow")}
  Translation catalogues would have this: "{TYPE} Mu", therefore gettext will look for it even though it will not exist because we, in fact, have these after the preprocessor is done:
  name= _ "Sword Mu"
  name= _ "Bow Mu"
  Since those are not in the catalogues, they will not get translated.

If you think a translatable string needs additional guidance to be translated properly, you can provide a special comment that will be seen by the translators. Just begin the comment with '#po:' above the string in question:

  #po: "northern marches" is *not* a typo for "northern marshes" here.
  #po: In archaic English, "march" means "border country".
  story=_ "The orcs were first sighted from the north marches of the great forest of Wesmere."

The gettext helper file

A gettext helper file is a lovely file that makes reusing mainline translations nice and easy. It is also more wmllint-friendly.

Here is an example of a gettext helper file:

  #textdomain wesnoth-lib
  #define STR_ICE
  _"Ice" #enddef
  #textdomain wesnoth-units
  #define STR_SWORD
  _"sword" #enddef

A typical name for gettext helper files is mainline-strings.cfg.

To use it, just wire it into your add-on and use the macros:


Getting your add-on into WesCamp

Now, to get your add-on into WesCamp, all you do is put this line into your add-on’s .pbl file and upload to the add-ons server:


And your add-on will eventually be uploaded to WesCamp.

How to contribute to this project


Translating add-ons works the same as translating mainline. All of the information about this already exists in the wiki (see the links below). The files you need are located in the project’s Github repositories (they might take a bit of effort to locate. Alternatively, you can use gettext.wesnoth.org). When they are translated, send them to AI/AI0867.

Before you start translating you should:

  • Look at the subpage of the add-on you wish to translate to see if someone is already working on it.
  • Contact the translation team for your target language for guidance.

If you have questions, join the #wesnoth channel on the Freenode IRC network and ask in there. Of course, you will also get answers if you ask your questions in the Translations & Internationalization forum, or e-mail AI/AI0867.

See Also