WesCamp

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 BerliOS and maintained by Torangan and Espreon. Add-ons are uploaded into the Subversion repository 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.

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 BerliOS and maintained by Torangan and Espreon. Add-ons are uploaded into the Subversion repository 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.

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.

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:

 [textdomain]
     name="wesnoth-Son_of_Haldric"
     path="data/add-ons/Son_of_Haldric/translations"
 [/textdomain]

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
  
  [unit_type]
      id=Mu
      name= _ "Mu"
      ...
  [/unit_type]

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
   
   [unit_type]
       id=Mu
       name= _ "Mu"
       ...
  
       [attack]
           id=sword
           #textdomain wesnoth-units
           description= _ "sword"
           ...
       [/attack]
  
       #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"
  #enddef
  
  {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.

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:

  [attack]
      id=sword
      name={STR_SWORD}
      ...
  [/attack]

  [terrain_type]
      id=ice2
      name={STR_ICE}
      ...
  [/terrain_type]

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:

  translate=true

Your add-on will eventually be uploaded to WesCamp’s Subversion repository by mordante’s script, which he runs whenever.

How to contribute to this project

Translators

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, mail them to Espreon or (as a last resort) Torangan.

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 Espreon or Torangan.