L10n how-to, written by Sébastien Desvignes, Cédric Corazza and Fabien Cazenave.

Welcome to the KompoZer l10n project!

For the new contributors to this project (and for the former ones), please mind to contact:

You can also contact us on the #kompozer IRC chan.

We will make once a day the pushes with your modifications:

/l10n/compare-locales
lists of all strings that are not translated yet
/l10n/langpacks
daily snapshot of the langpacks, for testing purposes
/l10n/jars
daily snapshot of the locale archives, for those who don't use the Mercurial repository (see below)

Translating KompoZer

There are three ways to translate KompoZer. If you're looking for the easiest method, jump to the Narro section.

KompoZer l10n for nerds: translate directly from the Mercurial repository

For those of you tech savvy, follow these steps to get the source from the repository:

  1. clone the repository: hg clone http://kompozer.hg.sourceforge.net:8000/hgroot/kompozer/kompozer
  2. make your modifications;
  3. zip your l10n directory;
  4. send it to the email address above, or drop a message on the newsgroup with a link to it.

This repository is read-only. Once the repository is cloned on your disk, updating it is a snap: hg pull -u

Testing: if you’re running Linux or MacOS X you can use the "convert-locales.py" script to build and test your langpack and before sending your l10n directory: 

./convert-locales.py make [localeID]

Disclaimer: no support is provided for this script.
We use these tools to ease the localization tasks, but we have no spare time to help you using them if you don't understand the notice usage.

KompoZer l10n for human beings: translate a locale archive

For those of you who don't know anything about Mercurial, just use the locale archives on /l10n/jars

  1. download and unzip the ZIP file that corresponds to your language: kompozer-xxx.de.zip, kompozer-xxx.pt-BR.zip (where xxx is the release number)…
  2. make your modifications (see compare-locales.log file to see what files/strings are missing);
  3. zip your locale directory;
  4. send it to the email address above or drop a message on the newsgroup with a link to it.

Compared to the Mercurial repository, there are two drawbacks:

Testing: you can test your langpack before sending it:

  1. open your KompoZer directory and get in the "chrome" subdirectory;
  2. rename "en-US.jar" as "en-US.bak";
  3. rename your locale ZIP file as "en-US.jar" and put it in KompoZer’s chrome directory;
  4. restart KompoZer to check your locale works properly.

Disclaimer: no support is provided for this mini-howto.
We suggest this for you to test your localization work, but we have no spare time to help you using them if you don't understand the notice usage.

KompoZer l10n in the browser: the Narro way

This is still a little experimental, but it’s by far the easiest way to work on KompoZer’s localization: no software to install, all you need is your favorite browser.

  1. First register on Narro by clicking on the Register link at the upper right corner of the page.
  2. Once logged in, click on the “Preferences” link at the upper-right corner of the page, and adjust them:
    • Items per page: is the number of strings displayed per page
    • Font size: just what it says
    • Language: the language to which you want to localize KompoZer —if not present, see step 3.
    • Application language: the language used for Narro user interface — the user interface in only available in English.
    • Special characters: characters that are not availble on your keyboard layout and that you would want to access quickly.
    • Other languages: other languages for which you would like to make suggestions.
    • Spellchecking: not available — if you use Firefox in your language with a dictionary installed, spellchecking will be enabled when editing forms.
    • Then, save your preferences by clicking on the Save button.
  3. Then, register to the l10n Mailing List and indicate in the subject the language you want to localize KompoZer to — as it is a moderated mailing list, you might have to wait for a day to be allowed to post.
  4. Once allowed, post in the mailing list: introduce yourself, give your Narro login id — so we can grant you the appropriate right for your locale — and ask for your language to be set up in Narro if neccessary. Please also indicate if your language is written right to left (RTL) or left to right (LTR).
  5. Once your language is set in Narro, log in, set your language in your preferences if necessary, and save your preferences.
  6. Now, click on the Projects link in the upper right corner of the page, then, in the upper left corner of the page, click on the project you want to localize in the column NAME.
  7. In the displayed page, in the upper left corner of the page, click on the project name (e.g. KompoZer 0.8) so that you will be brought to the root of your localization.
  8. In the new page that is displayed, you will see a drop-down list named “Show:” that allows you to filter the strings:
    • Untranslated texts: shows you all the strings that need to be localized. Click on the “Suggest/vote” link at the right of the string to translate it.
    • In the new page that is displayed, check the box “After approving, proceed to the next text” and the box “Approve after saving”. Enter your translation in the “Your suggestion” frame and click on the “Save” button to save it in the database and procedd with the next string.
    • When all the strings are done, select “Texts that require approval” in the drop-down list, and proceed like previously.
    • You can review/proofread all ths strings of KompoZer by selecting “All texts” in the drop-down list.
  9. When you think you are ok with your translation, ping us in the mailing or in IRC channel so we can generate for you your localized langpack.

Testing: not available. You'll have to wait for the langpack to be generated on kompozer.sf.net/l10/langpacks/.

The different types of files

DTD files (*.dtd)

See also: https://developer.mozilla.org/en/XUL_Tutorial/Localization

A DTD file contains a list of entities which need to be localized. The entities defined here are then used inside the user interface XUL files. An entity declaration looks like this:

<!ENTITY openCmd.label "Open Web Location…">

Above, to the entity with name/key "openCmd.label", has been assigned the value "Open Web Location…". The entity value is what needs to be localized. Usually the entity name (e.g. "openCmd.label") is self-explanatory: this one is the label of the Open menu command. If this is not enough, the author of the file adds a comment for the localizer. Comments referring to a particular entity are placed right above the entity declaration as:

<!-- LOCALIZATION NOTE (entity_name): comments -->

For example,

8 <!-- LOCALIZATION NOTE  throbber.url: DONT_TRANSLATE -->
9 <!ENTITY throbber.url "http://www.mozilla.org">

Remember you can't directly use the & < " % characters in your strings. Instead, substitute one of their predefined entities inside the string.

Property files (*.properties)

See also: https://developer.mozilla.org/en/XUL_Tutorial/Property_Files

As the name says, in these files a number of JavaScript properties (think about them as variables) are assigned with a string value. String resources in property files appear in the form:

property_name = Text Text Text

The string at the right side of the equal symbol is what needs to be localized. Again, localization notes and comments are often useful to explain what's the strings usage in the UI or a particular behavior the localizer should follow working on them:

25 #-----------------------------------------------------------
26 # LOCALIZATION NOTE InstallFile:...
27 #-----------------------------------------------------------
28 InstallFile=Installing: %s
29 ReplaceFile=Replacing: %s

As for the DTD files above, the same considerations apply to the files encoding. KompoZer will expect these files escaped Unicode encoded.

Remember to avoid the direct usage of backslash, single or double quotes in your strings. Use one of their substitutes instead. Don't break these strings on multiple lines.

Many strings contain strange symbols like %s or $1%s. They will be substituted at runtime by relevant words. Place them in your strings as it makes sense in the whole sentence, typing them exactly as found originally.

Data source files (*.rdf)

An RDF file usually contains a list of resources, e.g. a table of contents.

General considerations

UTF-8

All these documents are UTF-8 encoded. Hence, you'll need a text editor able to save the file in UTF-8 once modified. If you skip this step, you won't be able to display non-ASCII characters correctly, like diacritics or eastern scripts (i.e. all characters except a-z, A-Z, 0-9, !"#$%&'()*+,-./ :;<=>?@ _` {|}~).

There are a lot of good UTF-8 editors out there:

Warning: text files must be encoded without BOM (some text editors call this UTF-8N or UTF-8 cookie).
SciTE is another good text editor but it adds a BOM mark by default on utf-8 files: if you use SciTE, be sure to save your files in UTF-8 cookie format.

Help section

Translating the "help" directory is a lot of work, and unfortunately, this "help" section is quite outdated. So if you lack the time, you might want to skip its localization and use the English "help" directory instead.

Using English directories for any other section than "help" is not an option.

License

Please make sure that the license block in your locales files are the same than the en-US ones (especially for the existing locales). As this work is tri-licensed (MPL/GPL/LGPL), the localization should also follow this.

Check especially the /editor and /suite directories, as the other are generally taken from the Mozilla repository and should be OK.