Translation Maintenance Commands - Revision history

Pentarctagon at 22:57, 8 May 2023

2023-05-08T22:57:17Z

Egallager: a bit of cleanup (still very outdated)

2023-05-08T02:57:54Z

a bit of cleanup (still very outdated)

Pentarctagon at 01:40, 8 May 2023

2023-05-08T01:40:54Z

Celtic Minstrel: /* wmlxgettext */ Well that hasn't been true for years

2023-05-08T01:34:16Z

‎wmlxgettext: Well that hasn't been true for years

Celtic Minstrel: /* wmlxgettext */ Update information on documentation

2023-05-08T01:32:51Z

‎wmlxgettext: Update information on documentation

Octalot: /* Handling Localized Images */ Remove old l10n-track docs

2020-08-08T03:37:45Z

‎Handling Localized Images: Remove old l10n-track docs

Pentarctagon: Pentarctagon moved page Translation Maintainance Commands to Translation Maintenance Commands: Name mispelled.

2019-09-16T20:34:03Z

Pentarctagon moved page Translation Maintainance Commands to Translation Maintenance Commands: Name mispelled.

Aquileia: Update script location

2014-06-23T14:28:28Z

Update script location

Caslav.ilic: Out of sync localized images no longer need to be removed from the package.

2009-10-03T16:19:37Z

Out of sync localized images no longer need to be removed from the package.

Caslav.ilic: Handling localized images.

2009-04-13T22:46:58Z

Handling localized images.

@@ Line 1: / Line 1: @@
-This page is meant to document the current '''translation maintenance commands''' used for updating translation files that are sent in. Beside this it also is meant to list steps required to add new campaigns (importing from wescamp and changing textdomains) as well as new languages.
+This page is meant to document the current '''translation maintenance commands''' used for updating translation files that are sent in. Beside this it also is meant to list steps required to add new campaigns (changing textdomains) as well as new languages.
 This version is based on the stuff required as of 1.6.1. It is based on autotools/configure usage atm but should be easily adaptable to cmake and scons, too.
@@ Line 163: / Line 163: @@
 * update the language list of g.w.o: This requires getting a checkout of ''branches/resources/gettext.wesnoth.org/public_html/wesnoth-gettext/westats/''. Make sure to add the language to ''langs.php'' in this checkout, commit and ping someone with ssh access to wesnoth.org to run ''svn up'' as the user ''wesnoth'' inside $HOME/SOURCE/gettext.wesnoth.org to have the website updated, too.
-==adding translation files for a new campaign==
+Some other commands will have to be used; basically the "base files" (as described a lot above) have to be created. Most will be done via copy&paste. Of course the po files have to be created, too. For this to work (after adding the po/TEXTDOMAIN folder as well as the required hooks in configure.ac and po/Makefile.am) autogen.sh has to be run and a pot-update (using ''make update-po'') has to be done in the new textdomains folder to generate po/TEXTDOMAIN/TEXTDOMAIN.pot. Once the .pot file exists, the po files can easily be created with this command:
   cd po/TEXTDOMAIN/
   for i in `cat LINGUAS`; do msginit -l $i --no-translator; done
@@ Line 222: / Line 210: @@
 ===sanity-check===
 Checks if the src files listed in po/wesnoth*/POTFILES.in exist and if all files are listed. For this only the textdomains ''wesnoth'', ''wesnoth-editor'' and ''wesnoth-lib'' are considered since the other files should be WML only.
 ===wmlxgettext===

@@ Line 1: / Line 1: @@
-==Foreword==
+This page is meant to document the current '''translation maintenance commands''' used for updating translation files that are sent in. Beside this it also is meant to list steps required to add new campaigns (importing from wescamp and changing textdomains) as well as new languages.
-This version is based on the stuff required as of 1.6.1. It is based on autotools/configure usage atm but should be easily addaptable to cmake and scons, too.
+This version is based on the stuff required as of 1.6.1. It is based on autotools/configure usage atm but should be easily adaptable to cmake and scons, too.
 ==Prerequisites==
@@ Line 31: / Line 30: @@
 ===*.po===
-These are the "real" translation files. They are named after the language they belong to, based on the "langcodes" for those. Eg the file for the german translation is named de.po. With these files translators do work and from these the .mo files are created when "compiling" them. The files basically consist of a header, an area of "active strings" (starting right after the header) and and area used for "old and now unused" strings (commented out using lines starting with ''#~''. All lines starting with a # are commented out, though there are various kinds of comments. These comments are defined by gettext, here a short explaination about them and their syntax, basically the beginning of the lines defines the type:
+These are the "real" translation files. They are named after the language they belong to, based on the "langcodes" for those. For example, the file for the [[GermanTranslation|German translation]] is named de.po. With these files translators do work and from these the .mo files are created when "compiling" them. The files basically consist of a header, an area of "active strings" (starting right after the header) and and area used for "old and now unused" strings (commented out using lines starting with ''#~''. All lines starting with a # are commented out, though there are various kinds of comments. These comments are defined by gettext, here a short explanation about them and their syntax, basically the beginning of the lines defines the type:
 * ''#. My Text'': ''My Text'' is some automatically extracted comment from the sources (translation hints, status stuff, all this foo).
 * ''#, fuzzy'': This string was seen as "reasonably close but not identical" when the file was updated. Translators should check this string and remove this line if the translation is correct. Unless this is done, the string is not shown translated in the program. This is the complete content of the line
@@ Line 39: / Line 38: @@
 In general translations in the po file consist over (several) of those comments and two other blocks:
 * msgid "Original String": the original string used that the translators have to work on.
-* msgstr "Translated Version": the string that is used as replacement when the translation this file belongs to is used and a case of "Original String" is meat (where the original has to be marked as translateable!).
+* msgstr "Translated Version": the string that is used as replacement when the translation this file belongs to is used and a case of "Original String" is meat (where the original has to be marked as translatable!).
 In general each of those strings can span over several lines, but to have a newline in the translation (or original) an explicit ''\n'' has to be added. The only constant thing is that strings have to be encapsulated by " and only the stuff inside of the " counts. Additionally to those "normal forms" the strings can also exists as plurals, here an example from the game and a corresponding German translation ([0] means singular, [1] means first plural form, [2] means 2nd plural form and so on):
   #: src/actions.cpp:2485
@@ Line 71: / Line 70: @@
 ===Makevars===
-This file in each textdomain dir is for some varibales used by autotools when generating files. Don't ask for what exactly it is, in general it has not to be touched by humans at all. The only thing you should make sure is to add correct entries for textdomains in the ''DOMAIN = '' lines.
+This file in each textdomain dir is for some variables used by autotools when generating files. Don't ask for what exactly it is, in general it has not to be touched by humans at all. The only thing you should make sure is to add correct entries for textdomains in the ''DOMAIN = '' lines.
 ===CMakeLists.txt===
@@ Line 80: / Line 79: @@
 ===Generated files===
-Basically all the others files not listed here are generated by the build systems (or specific for documentation/po4a related stuff, described below). That especially includes *.mo or *,gmo files which include the "compiled" translations in a form that gettext can directly use them ingame, too.
+Basically all the others files not listed here are generated by the build systems (or specific for documentation/po4a related stuff, described below). That especially includes *.mo or *.gmo files which include the "compiled" translations in a form that gettext can directly use them in-game, too.
 ===Documentation/po4a specific stuff===
@@ Line 86: / Line 85: @@
 '''po4a based textdomain only''' (normally autogenerated by autotools)
-A hardcoded makefile for po4a stuff. This should eventually be replaced by a generated file from eg cmake. Maybe ettin knows more about this stuff...
+A hardcoded makefile for po4a stuff. This should eventually be replaced by a generated file from e.g. cmake. Maybe ettin knows more about this stuff...
 ====TEXTDOMAIN.cfg====
 '''po4a based textdomain only'''
-A file with some po4a based config, also duplicating some stuff that normally would be available eg in LINGUAS. This should eventually be changed in some way, too. ATM it is there because, hmm, it is there... Some po4a specific variables are configured here, maybe ettin knows more about this stuff...
+A file with some po4a based config, also duplicating some stuff that normally would be available e.g. in LINGUAS. This should eventually be changed in some way, too. ATM it is there because, hmm, it is there... Some po4a specific variables are configured here, maybe ettin knows more about this stuff...
 ====manpages====
@@ Line 135: / Line 134: @@
 When not using bash, do so by hand or write yourself your own script...
-When all of the commands were successfull, just commit the files using ''svn ci'', but make sure that the language is already added in ''changelog'' as well as ''players_changelog''. Using those steps the doc files are *not* regenerated since regenerating doc files takes quite some time. This is only down every now and then for all the doc files (mainly when a pot-update is run, too).
+When all of the commands were successful, just commit the files using ''svn ci'', but make sure that the language is already added in ''changelog'' as well as ''players_changelog''. Using those steps the doc files are *not* regenerated since regenerating doc files takes quite some time. This is only down every now and then for all the doc files (mainly when a pot-update is run, too).
-To sum things up, here all the commands used ($2 is the LANGCODE, commiting after this stuff if no error occurred and everything is as it should be):
+To sum things up, here all the commands used ($2 is the LANGCODE, committing after this stuff if no error occurred and everything is as it should be):
   echo "executing update script"
   echo "switching to "$LANGDIR
@@ Line 158: / Line 157: @@
 * make sure the files really compile (basically check if the plural forms and the rest of the header is fine by trying to compile everything normally; a problematic case is eg ''"Project-Id-Version: PACKAGE VERSION\n"'' in the textdomain ''wesnoth'')
 * add ''data/languages/langcode_COUNTRYCODE.cfg'' (should look like the other files, too; required to have the file in the lang selection list ingame)
-* add language to ''data/core/about.cfg'' (can be a dummy entry for the moment, this is mainly for other langs to have this string among their translateable strings as soon as possible.
+* add language to ''data/core/about.cfg'' (can be a dummy entry for the moment, this is mainly for other langs to have this string among their translatable strings as soon as possible.
 * add all the new files to svn and commit (from the checkouts root):
   svn add po/wesnoth*/LANG-CODE.po data/languages/langcode_COUNTRYCODE.cfg
@@ Line 257: / Line 256: @@
   foo/bar/l10n/LANG/image--overlay.png

@@ Line 219: / Line 219: @@
 ===pofix.py===
-A program to fix tiny spelling mistages over all textdomains. Ask esr for details (like how to add fixes and such).
+A program to fix tiny spelling mistakes over all textdomains. Ask on the forums for details on how to add fixes to it.
 ===sanity-check===

@@ Line 228: / Line 228: @@
 ===wmlxgettext===
-This script is used to extract translateable files from WML files. The file in utils/ is written in perl and esr is currently working on a replacement written in python. This is available as data/tools/wmlxgettext and requires some more testing. For usage info, see the [https://wmlxgettext-unoff.readthedocs.io automated documentation] and [[GettextForWesnothDevelopers#Marking up strings in WML|developer translation guidelines]].
+This script is used to extract translateable files from WML files. This is available as data/tools/wmlxgettext and requires some more testing. For usage info, see the [https://wmlxgettext-unoff.readthedocs.io automated documentation] and [[GettextForWesnothDevelopers#Marking up strings in WML|developer translation guidelines]].
 [[Category:Translations]]

@@ Line 228: / Line 228: @@
 ===wmlxgettext===
-This script is used to extract translateable files from WML files. The file in utils/ is written in perl and esr is currently working on a replacement written in python. This is available as data/tools/wmlxgettext and requires some more testing. For usage info, ask esr since he probably knows best how to handle wmlxgettext.
+This script is used to extract translateable files from WML files. The file in utils/ is written in perl and esr is currently working on a replacement written in python. This is available as data/tools/wmlxgettext and requires some more testing. For usage info, see the [https://wmlxgettext-unoff.readthedocs.io automated documentation] and [[GettextForWesnothDevelopers#Marking up strings in WML|developer translation guidelines]].
 [[Category:Translations]]

← Older revision		Revision as of 03:37, 8 August 2020
Line 257:		Line 257:

	foo/bar/l10n/LANG/image--overlay.png		foo/bar/l10n/LANG/image--overlay.png
−
−	~~Then, to register the new localized image with tracking system (see [[#Image Synchronization\|below]]), the maintainer executes the tracker script in the branch root directory:~~
−
−	~~$ lbundle-check.py~~
−	~~A foo/bar/l10n/LANG~~
−	~~A (bin) foo/bar/l10n/LANG/image.png~~
−	~~M l10n-track~~
−	~~--------------------~~
−	~~New 'ok': 1~~
−	~~./foo/bar/l10n/LANG/image.png (./foo/bar/image.png 30534)~~
−	$
−
−	~~The tracker script will add any new images (and their directories) to version control, and add an entry for this image to the global tracking file <tt>l10n-track</tt>:~~
−
−	~~ok ¦foo/bar/l10n/LANG/image.png¦ 5c3e43227fd07391faf441450d623543 30534~~
−
−	~~Then the maintainer just commits everything (including <tt>l10n-track</tt>).~~
−
−	~~=== Receiving Modified Images ===~~
−
−	Everything as when a new image is received, except that ''prior'' to running tracker script, the line of the image in <tt>l10n-track</tt> should be manually removed. This will make the tracker script register the modified image as matching the current original, with <tt>ok</tt> status (it may have been <tt>fuzzy</tt> before).
−
−	In fact, to remove the entry line from <tt>l10n-track</tt> is strictly necessary only if the old status is <tt>fuzzy</tt>. But it's good to do it even if status was <tt>ok</tt>, to get expected feedback when the tracker script is run, signaling proper placement of received image.
−
−	~~=== Tracking Synchronization to Original ===~~
−
−	From time to time the original image will have been moved, removed, or modified, and localized images need to follow this change. To detect such conditions, the maintainer periodically (e.g. sufficiently before the impending release) runs the [https://gitorious.org/scripty/scripty/source/master:l10n-support/lbundle-check.py tracker script] in root directory of the branch, without any arguments, e.g.:
−
−	~~$ cd $REPOSITORY/trunk/~~
−	~~$ lbundle-check.py~~
−
−	~~If all localized and original images are in sync, there will be no output.~~
−
−	~~If an original image was modified, the tracker script will notify about it in output, and change the status of corresponding localized images in <tt>l10n-track</tt> to <tt>fuzzy</tt>:~~
−
−	~~fuzzy ¦foo/bar/l10n/LANG/image.png¦ 5c3e43227fd07391faf441450d623543 30534~~
−
−	The third and fourth field here are the checksum and revision ID of the ''old'' original, to which the localized image was synced. In only some images were fuzzied, maintainer can just commit the <tt>l10n-track</tt> file and be done with it. (Old original revision ID is what translators can use later to compare the changes in the original, modify the localized image accordingly, and send in the updated version.) Alternatively, if in good mood, maintainer could also check in repository log if perhaps the original just got compressed, i.e. there were no visible changes, and manually unfuzzy all the localized images (by removing their lines from <tt>l10n-track</tt> and rerunning the tracker).
−
−	If an original image got moved or removed, the status of corresponding localized images will be set to <tt>obsolete</tt>. Then the maintainer should examine what happend to the original image: if it got moved, move localized images accordingly, and if it got removed, remove localized images as well. Then, remove obsolete entries from <tt>l10n-track</tt>, rerun the tracker, and commit moves/removals and modified <tt>l10n-track</tt>.
−
−	The setup for the tracker script is in <tt>l10n-spec</tt> file in the root directory, next to <tt>l10n-track</tt> file. It has very few and self-explanatory settings in form of <tt>key=value</tt> pairs. Only the first of those setting needs to be periodically updated:
−
−	~~# List of language codes that have at least one localized file.~~
−	~~languages = sv fr ...~~
−
−	~~as languages send their first localized images in ((alternatively, just mirror contents of <tt>po/LINGUAS</tt> as the value)).~~

← Older revision	Revision as of 20:34, 16 September 2019
(No difference)

@@ Line 283: / Line 283: @@
 === Tracking Synchronization to Original ===
-From time to time the original image will have been moved, removed, or modified, and localized images need to follow this change. To detect such conditions, the maintainer periodically (e.g. sufficiently before the impending release) runs the [http://websvn.kde.org/*checkout*/trunk/l10n-support/scripts/lbundle-check.py tracker script] in root directory of the branch, without any arguments, e.g.:
+From time to time the original image will have been moved, removed, or modified, and localized images need to follow this change. To detect such conditions, the maintainer periodically (e.g. sufficiently before the impending release) runs the [https://gitorious.org/scripty/scripty/source/master:l10n-support/lbundle-check.py tracker script] in root directory of the branch, without any arguments, e.g.:
   $ cd $REPOSITORY/trunk/

← Older revision		Revision as of 16:19, 3 October 2009
Line 304:		Line 304:

	as languages send their first localized images in ((alternatively, just mirror contents of <tt>po/LINGUAS</tt> as the value)).		as languages send their first localized images in ((alternatively, just mirror contents of <tt>po/LINGUAS</tt> as the value)).
−
−	~~=== Omitting Out-of-Sync Images From Release ===~~
−
−	When the release is prepared, out-of-sync images should be removed from the package, in order for players not to see outdated, possibly misleading localized images -- just as it happens with fuzzy messages in PO files. To do this, it is sufficient to execute in the package root (where <tt>l10n-track</tt> will reside):
−
−	~~$ egrep '^(fuzzy\|obsolete)' l10n-track \| sed 's/.¦\(.\)¦.*/\1/' \| xargs rm~~

← Older revision		Revision as of 22:46, 13 April 2009
Line 233:		Line 233:
	[[Category:Development]]		[[Category:Development]]
	[[Category:Tools]]		[[Category:Tools]]
		+
		+	== Handling Localized Images ==
		+
		+	Translators may localize any in-game image they want. These should mostly be images with some English text on them, like main logo, maps, and in-game help screenshots. Localized images come in two varieties:
		+
		+	* standalone localized images -- localized images which totally replace the original image, when the modified area of the image is great enough (e.g. logo);
		+
		+	* localized overlay images -- images mostly transparent but for some isolated spots, which are are composed with the original at runtime, when the modified area is too small to waste space using a standalone localized image (e.g. maps).
		+
		+	For translators' view of the process, see [[User_talk:Caslav.ilic/ImageLocalization\|the separate article]].
		+
		+	=== Receiving New Images ===
		+
		+	When translator sends in a localized image, the maintainer should locate its original counterpart, and place the localized image into the <tt>l10n/LANG</tt> subdirectory of the original image's directory (where <tt>LANG</tt> is the appropriate language code). E.g. if the original image path is:
		+
		+	foo/bar/image.png
		+
		+	then the standalone localized image will have the same name, and be placed as:
		+
		+	foo/bar/l10n/LANG/image.png
		+
		+	and the overlay image will have <tt>--overlay</tt> suffix (note ''two'' hyphens):
		+
		+	foo/bar/l10n/LANG/image--overlay.png
		+
		+	Then, to register the new localized image with tracking system (see [[#Image Synchronization\|below]]), the maintainer executes the tracker script in the branch root directory:
		+
		+	$ lbundle-check.py
		+	A foo/bar/l10n/LANG
		+	A (bin) foo/bar/l10n/LANG/image.png
		+	M l10n-track
		+	--------------------
		+	New 'ok': 1
		+	./foo/bar/l10n/LANG/image.png (./foo/bar/image.png 30534)
		+	$
		+
		+	The tracker script will add any new images (and their directories) to version control, and add an entry for this image to the global tracking file <tt>l10n-track</tt>:
		+
		+	ok ¦foo/bar/l10n/LANG/image.png¦ 5c3e43227fd07391faf441450d623543 30534
		+
		+	Then the maintainer just commits everything (including <tt>l10n-track</tt>).
		+
		+	=== Receiving Modified Images ===
		+
		+	Everything as when a new image is received, except that ''prior'' to running tracker script, the line of the image in <tt>l10n-track</tt> should be manually removed. This will make the tracker script register the modified image as matching the current original, with <tt>ok</tt> status (it may have been <tt>fuzzy</tt> before).
		+
		+	In fact, to remove the entry line from <tt>l10n-track</tt> is strictly necessary only if the old status is <tt>fuzzy</tt>. But it's good to do it even if status was <tt>ok</tt>, to get expected feedback when the tracker script is run, signaling proper placement of received image.
		+
		+	=== Tracking Synchronization to Original ===
		+
		+	From time to time the original image will have been moved, removed, or modified, and localized images need to follow this change. To detect such conditions, the maintainer periodically (e.g. sufficiently before the impending release) runs the [http://websvn.kde.org/checkout/trunk/l10n-support/scripts/lbundle-check.py tracker script] in root directory of the branch, without any arguments, e.g.:
		+
		+	$ cd $REPOSITORY/trunk/
		+	$ lbundle-check.py
		+
		+	If all localized and original images are in sync, there will be no output.
		+
		+	If an original image was modified, the tracker script will notify about it in output, and change the status of corresponding localized images in <tt>l10n-track</tt> to <tt>fuzzy</tt>:
		+
		+	fuzzy ¦foo/bar/l10n/LANG/image.png¦ 5c3e43227fd07391faf441450d623543 30534
		+
		+	The third and fourth field here are the checksum and revision ID of the ''old'' original, to which the localized image was synced. In only some images were fuzzied, maintainer can just commit the <tt>l10n-track</tt> file and be done with it. (Old original revision ID is what translators can use later to compare the changes in the original, modify the localized image accordingly, and send in the updated version.) Alternatively, if in good mood, maintainer could also check in repository log if perhaps the original just got compressed, i.e. there were no visible changes, and manually unfuzzy all the localized images (by removing their lines from <tt>l10n-track</tt> and rerunning the tracker).
		+
		+	If an original image got moved or removed, the status of corresponding localized images will be set to <tt>obsolete</tt>. Then the maintainer should examine what happend to the original image: if it got moved, move localized images accordingly, and if it got removed, remove localized images as well. Then, remove obsolete entries from <tt>l10n-track</tt>, rerun the tracker, and commit moves/removals and modified <tt>l10n-track</tt>.
		+
		+	The setup for the tracker script is in <tt>l10n-spec</tt> file in the root directory, next to <tt>l10n-track</tt> file. It has very few and self-explanatory settings in form of <tt>key=value</tt> pairs. Only the first of those setting needs to be periodically updated:
		+
		+	# List of language codes that have at least one localized file.
		+	languages = sv fr ...
		+
		+	as languages send their first localized images in ((alternatively, just mirror contents of <tt>po/LINGUAS</tt> as the value)).
		+
		+	=== Omitting Out-of-Sync Images From Release ===
		+
		+	When the release is prepared, out-of-sync images should be removed from the package, in order for players not to see outdated, possibly misleading localized images -- just as it happens with fuzzy messages in PO files. To do this, it is sufficient to execute in the package root (where <tt>l10n-track</tt> will reside):
		+
		+	$ egrep '^(fuzzy\|obsolete)' l10n-track \| sed 's/.¦\(.\)¦.*/\1/' \| xargs rm