Difference between revisions of "Translation Guidelines"

From LXDE.org
Jump to: navigation, search
m (Adding link to page in french)
(Simplifying page. Fixing grammatical errors)
Line 1: Line 1:
Translators of many free software applications have discovered that the best and most comfortable way of ensuring updated, consistent and high-quality translations is generally one that involves the following steps:
+
Translators of many free software applications have discovered that the best and most comfortable way of ensuring updated, consistent and high-quality translations are generally one that involves the following steps:
 
 
 
1. Translator runs a command to fetch updated translation files.
 
1. Translator runs a command to fetch updated translation files.
 
2. Translator ‘updates’ the translation.
 
2. Translator ‘updates’ the translation.
3. Translator runs command to send translation files to the project.
+
3. Translator runs the command to send translation files to the project.
  
Point 1 and 3 may for example consist of ‘svn update’ and ‘svn commit’. Point 2 may involve using a localisation application such as Lokalize in KDE, but may also involve other tools. For example, the Norwegian Nynorsk team uses the Pology tools to automatically add translation suggestions from a large compendium we use, and to automatically run a number of automatic checks to ensure the translation conforms to our linguistic guidelines (these checks also find a number of common translation mistakes).
+
Point 1 and 3 may, for example, consist of ‘svn update’ and ‘svn commit’. Point 2 may involve using a localization application such as Lokalize in KDE, but may also involve other tools. For example, the Norwegian Nynorsk team uses the Pology tools to automatically add translation suggestions from a large compendium we use and to automatically run a number of automatic checks to ensure the translation conforms to our linguistic guidelines (these checks also find a number of common translation mistakes).
  
 
Currently, for LXDE, the workflow follows these points, but the details differ:
 
Currently, for LXDE, the workflow follows these points, but the details differ:
 
+
1. Run a custom script to do ‘svn up’ on the various folders. It then runs ‘intltool-update --POT’ in the ‘PO’ folders to update the POT files, followed by a msgmerge operation on the .po files, which I store in another repository. The reason translators do this twofold: One is that the LXDE makefiles do not specify the ‘--previous’ option to ‘msgmerge’, making it very difficult figuring how a changed string has changed. A custom ‘msgmerge’ command does. The second is that translators can use a compendium (based on KDE and OpenOffice.org, among other apps) to insert auto-translated suggestions for new strings.
1. Run a custom script to do ‘svn up’ on the various folders. It then runs ‘intltool-update --POT’ in the ‘po’ folders to update the POT files, followed by a msgmerge operation on the .po files, which I store in another repository. The reason translators do this twofold: One is that the LXDE makefiles do not specifiy the ‘--previous’ option to ‘msgmerge’, making it very difficult figuring how a changed string has changed. A custom ‘msgmerge’ command does. The second is that translators can use a compendium (based on KDE and OpenOffice.org, among other apps) to insert auto-translated suggestions for new strings.
 
  
 
2. As above.
 
2. As above.
Line 16: Line 14:
  
 
Any workflow that makes steps 1, 2 and 3 possible would IMHO be very important. A preferred one for many translators is based on ‘svn up‘ and ‘svn commit’. One based on manually checking a Web site, clicking on individual files for download and upload, or having to work on the online, would not be ‘acceptable’.
 
Any workflow that makes steps 1, 2 and 3 possible would IMHO be very important. A preferred one for many translators is based on ‘svn up‘ and ‘svn commit’. One based on manually checking a Web site, clicking on individual files for download and upload, or having to work on the online, would not be ‘acceptable’.
 
  
 
[[Category:Translations]]
 
[[Category:Translations]]
 
 
[[fr:Directives de traduction]]
 
[[fr:Directives de traduction]]

Revision as of 16:17, 18 September 2019

Translators of many free software applications have discovered that the best and most comfortable way of ensuring updated, consistent and high-quality translations are generally one that involves the following steps: 1. Translator runs a command to fetch updated translation files. 2. Translator ‘updates’ the translation. 3. Translator runs the command to send translation files to the project.

Point 1 and 3 may, for example, consist of ‘svn update’ and ‘svn commit’. Point 2 may involve using a localization application such as Lokalize in KDE, but may also involve other tools. For example, the Norwegian Nynorsk team uses the Pology tools to automatically add translation suggestions from a large compendium we use and to automatically run a number of automatic checks to ensure the translation conforms to our linguistic guidelines (these checks also find a number of common translation mistakes).

Currently, for LXDE, the workflow follows these points, but the details differ: 1. Run a custom script to do ‘svn up’ on the various folders. It then runs ‘intltool-update --POT’ in the ‘PO’ folders to update the POT files, followed by a msgmerge operation on the .po files, which I store in another repository. The reason translators do this twofold: One is that the LXDE makefiles do not specify the ‘--previous’ option to ‘msgmerge’, making it very difficult figuring how a changed string has changed. A custom ‘msgmerge’ command does. The second is that translators can use a compendium (based on KDE and OpenOffice.org, among other apps) to insert auto-translated suggestions for new strings.

2. As above.

3. A command to run ‘svn diff‘ followed by gzip, and the (manually) sending the gzipped diff to the mailing list (or the tracker).

Any workflow that makes steps 1, 2 and 3 possible would IMHO be very important. A preferred one for many translators is based on ‘svn up‘ and ‘svn commit’. One based on manually checking a Web site, clicking on individual files for download and upload, or having to work on the online, would not be ‘acceptable’.