Language Pack Development

From AlfrescoWiki

Jump to: navigation, search

Alfresco uses standard Java message bundles to provide localized messages within the application. This allows language pack authors to develop translations without needing to modify any core Alfresco files. Language packs for Alfresco simply consist of a number of text files containing the localized messages plus a short README and glossary file.

No special programming knowledge is required to start developing a language pack, however it is recommended that authors have a knowledge of source control systems such as Subversion which will allow you to keep track of all changes which you make to the translation. All projects set up on the Alfresco Forge automatically have a Subversion repository (as well as CVS) available to them, which you can use during your development.

Contents

[edit] What Can Be Translated?

Almost all parts of the Alfresco application can be localized by language pack authors, including the following main components.

  • The Alfresco Explorer web client
  • The Alfresco Share collaboration application
  • Content model labels (types, aspects, property names, etc.)
  • System-level messages (e.g. for logging)

All components other than Share are composed of a number of message files which can be easily installed by placing them in the alfresco.messages package on your classpath. For Tomcat installations, the normal directory used would be tomcat/shared/classes/alfresco/messages within your Alfresco installation.

Slingshot components are based on a different internationalization framework which requires message files to be broken down into various sub-folders. This has implications for how your language pack structure should be set up.

[edit] Language Pack Structure

You are recommended to set up your language pack with the following directory structure, which will allow you to easily package up your project for testing and distribution. This layout is also designed to be consistent with that used for AMP Files making it easy to package your language pack up in this manner if you wish. 

/
|
|- config/
  |
  |- alfresco/
    |
    |- messages/
      |
      |- action-config_xx_XX.properties
      |
      |- action-service_xx_XX.properties
      |
      | ...
      |
      |- workflow-interpreter-help_xx_XX.properties
    |
    |- site-webscripts/
      |
      |- org/
        |
        |- alfresco/
          |
          |- components/
            |
            |- calendar/
            |
            |- ...
            |
            |- title/
          |
          |- modules/
|
|- glossary_xx_XX.txt
|
|- readme_xx_XX.txt
|
|- project-build.xml (optional)

All files within the language pack should have the appropriate suffix for your language and country, shown here as _xx_XX (e.g. _fr_FR for French, _fr_CA for Canadian French. See Localising resource bundles for more information.

The project directory structure can be broken down as follows:

  • config/alfresco contains all message bundle files for containing your localized strings within two subdirectories,
    • messages containing all global messages for the repository, web client and Slingshot
    • and site-webscripts containing messages for all translated Slingshot modules and components
  • glossary_xx_XX.txt should contain a standardized list of all common terms used in your translation to ensure consistency is maintained. At a minimum you should look to document all terms from the Glossary of Terms in this file.
  • readme_xx_XX.txt should contain basic information about the language pack such as the details of all maintainers and any relevant project information such as acknowledgements or how to contribute.
  • project-build.xml can optionally be included to automate building and installation of your language pack using Ant.

[edit] Translation Tools

At the most basic level, all that is required to develop a language pack is a simple text editor. However since language packs usually consist of a number of files some of which can contain several hundred messages, you may wish to consider using a more specialized translation tool such as the ones listed below. Some of these tools also provide other benefits such as translation memories which will assist you during the translation process and automatic highlighting of untranslated messages.

The following is a list of free and open source applications which have been used by other translators to help with their localization efforts. Note that these will vary greatly in the way in which they work and the capabilities they provide, but if you choose a tool which supports standards such as XLIFF or TMX this will allow others to use a different tool of their choice.

Attesoro is a Java-based application which provides simple file-based editing of your translations, automatic encoding of characters, and highlighting of untranslated entries. You can download it from http://attesoro.org/, then simply start it and open one of the *_en_US.properties files to start translating. Note that Attesoro is known to have issues encoding some quotation marks correctly and you will need to manually fix these afterwards.

OmegaT provides more advanced capabilities such as fuzzy matching, translation memory, keyword search, glossaries, and translation leveraging into updated projects based on the TMX format. See http://www.omegat.org/en/omegat.html.

The Open Language Tools are a set of translation tools, using standards such as XLIFF & TMX to manage localized messages. Available from http://open-language-tools.dev.java.net.

Properties Editor can directly edit property files written in Unicode reference characters, and saves the time and effort of converting into Unicode through native2ascii. In addition to the usual functions of an editor, the plugin is integrated with Eclipse and JBuilder. Files can be opened in the IDE and saved in Unicode. For details, see http://propedit.sourceforge.jp/index_en.html.

The native2ascii tool bundled with Sun's JDK can be used to ensure that non-ASCII characters in your message bundle files are correctly encoded and can be useful if your editor does not fully support automatic encoding.

Virtaal provides rich translation memory from various sources, searching, glossaries, etc. It supports XLIFF and PO editing. http://virtaal.org

Translate Toolkit provides a prop2po tool that is able to convert Java properties files into Gettext PO files. This allows a translator to make use of any FOSS translation tool such as Virtaal. http://translate.sourceforge.net/wiki/toolkit/index

[edit] More Information

Retrieved from "http://wiki.alfresco.com/wiki/Language_Pack_Development"