0.9.1+ Changes to translating user campaigns in wesnoth

[Ayin]

Hi everybody,

The syntax to translate user campaigns has changed in 0.9.0 . Actually, it was broken in 0.9.0, and will be fixed in 0.9.1, thanks to Torangan who noticed this.

Before the change, to translated user campaigns, one had to add the "translations" and "textdomain" WML pseudo-variables in any element containing translatable text. For example, each scenario from Liberty was prefixed with:

Code: Select all

[scenario]
	translations=data/campaigns/Liberty/translations
	textdomain=wesnoth-Liberty

This did bind the "wesnoth-Liberty" gettext-domain to data/campaigns/Liberty/translations, and made the strings below be translated in the wesnoth-Liberty domain.

Now, each scenario from Liberty must be prefixed with:

Code: Select all

[scenario]
#textdomain wesnoth-Liberty

The #textdomain directive specifies that each translatable string, from now to the end of the current element (or the next #textdomain directive) will be in the wesnoth-Liberty domain.

And furthermore, the main campaign file, Liberty.cfg, must contain the following lines, which tell the engine where to find the translations for a given textdomain:

Code: Select all

[textdomain]
	name="wesnoth-Liberty"
	path="data/campaigns/Liberty/translations"
[/textdomain]

Edit: I was not explicit enough: [textdomain] is a new top-level WML element, not a child of [campaign].

Thus, [textdomain] must directly go at the root of the "Scenario.cfg" file, not inside the [campaign] tags.

Regards,

Ayin

[MadMax]

Now, each scenario from Liberty must be prefixed with:

Does that mean I am supposed to take the old code out?

And furthermore, the main campaign file, Liberty.cfg, must contain the following lines

In the [campaign] tag, or just the file?

Also, is this acceptable for a path, or are my slashes wrong?

Code: Select all

path="/data/campaigns/Flight_Freedom/translations"

[Ayin]

Now, each scenario from Liberty must be prefixed with:

Does that mean I am supposed to take the old code out?

Not necessarily, it won't break anything if you let it here.

And furthermore, the main campaign file, Liberty.cfg, must contain the following lines

In the [campaign] tag, or just the file?

Also, is this acceptable for a path, or are my slashes wrong?

Code: Select all

path="/data/campaigns/Flight_Freedom/translations"

The slash before the strings should not be there, it should be

Code: Select all

path="data/campaigns/Flight_Freedom/translations"

(However, it may work with the slash, I did not test)

[MadMax]

Now, each scenario from Liberty must be prefixed with:

every scenario or every element?

[scott]

Does the campaign.cfg file ALSO need

Code: Select all

#textdomain wesnoth-Liberty

in addition to

Code: Select all

[textdomain]
name="wesnoth-Liberty"
path="data/campaigns/Liberty/translations"
[/textdomain]

to handle the translatable text in the file?

[Ayin]

Yep. You need to:

* replace each "textdomain=" line by the equivalent "#textdomain" directive (you can have both, though, although the former will be ignored)
* add a textdomain declaration in your Campaign.cfg, like this:

Code: Select all

[textdomain]
name="wesnoth-Liberty"
path="data/campaigns/Liberty/translations"
[/textdomain] 

[Ayin]

Now, each scenario from Liberty must be prefixed with:

every scenario or every element?

If the elements are set like that:

Code: Select all

[e1]
        #textdomain blah
        [e2]
                value= _ "Translatable"
        [/e2]
[/e1]

Then, e2 will implicily inherit the textdomain of e1. So, just setting #textdomains in scenarios should just mark all strings in the scenario, and in the children of the scenario, in the correct textdomain.

[Ayin]

I was not explicit enough: [textdomain] is a new top-level WML element, not a child of [campaign].

Thus, [textdomain] must directly go at the root of the "Scenario.cfg" file, not inside the [campaign] tags.

Ayin

[scott]

Example?

Code: Select all

[textdomain]
	name="wesnoth-Liberty"
	path="data/campaigns/Liberty/translations"
[/textdomain]
[campaign]

	#textdomain wesnoth-Liberty

	id=liberty
	name= _ "Liberty"
	define=CAMPAIGN_LIBERTY
 
... etc...

[Ayin]

scott: Yep, thanks for the example (it is indeed correct).

Cheers,

Ayin

[MadMax]

Does the #textdomain line have to be in the unit .cfgs too?

[scott]

Yes. However, the argument of the #textdomain command can be wesnoth or wesnoth-yourdomain.

For example, I have modified skeletons and revenants but their text (name, description, and weapon name) is unchanged, so they have #textdomain wesnoth.

I have modified L2 outlaws with modified text, so they are in #textdomain wesnoth-Liberty. All the custom units have #textdomain wesnoth-Liberty.

[yann]

I just committed support to extract messages belonging to several domains from a single .cfg file. Beware, it has side-effects that may require updates to some of your campaign files.

The disrupting change is that the #textdomain tags also has to be added in cfg files included from the scenarios (files like utils.cfg or deaths.cfg in the official campaigns).

As explained in the commit message, think about your files being included by another campaign instead: the messages must be looked for in the correct domain in this case too. That is, if I understand well the current implementation, where the scope of #textdomain is the enclosing WML block, you must for example add #textdomain tags in the relevant wml blocks of the each macro (assuming each macro with a translatable string has a wml block). Look at those files in CVS as an example.

The benefit is that you can now switch a block to the wesnoth textdomain, to avoid duplicating standard translations in your own domain. Be aware of a limitation of the current implementation: the wmlxgettext string extractor does not know the scope of the #textdomain directive yet, so if you use this feature, you must add a #textdomain after your block, as follows:

Code: Select all

#textdomain wesnoth-foo
my=_"text"
[unit]
  #textdomain wesnoth
  description=_"standard text"
[/unit]
#textdomain wesnoth-foo
other=_"without the above directive, this text would be extracted as if in wesnoth domain instead, altough it will be searched in wesnoth-foo at runtime"

[silene]

#textdomain directives are no longer WML-scoped. See http://www.wesnoth.org/forum/viewtopic.php?t=5838 for additional details.

[ILikeProgramming]

If you have included the tags but there isn't a single translation yet, is wesnoth.exe supposed to launch?