Internationalization/tool evaluation

Revision as of 08:53, 3 May 2006 by Cconti (Talk | contribs) (KBabel)

About: Tool Evaluation

In this section it will be discussed which tool should be taken for the i18n work.

What should the tools be able to do

  • Search the source code for strings and other things that needs to be changed
  • Create a file containing these results
  • Enable the change of language and format of Eiffel

Tasks

The tools we should analyse have several tasks:

  • find the strings into the source code and extract them
  • find "information" about specific formats (time, measure units,...) in the code
  • give the possibility to translate in a friendly environment
  • replace the string with a function(string) construct

Here you'll find the advantages and drawbacks of every tool we evaluate.

Tools to evaluate

Here is the list of existing tools we are now evaluating:

GNU gettext

This set of tool is funded by the GNU community and is meant to help internationalize the C-Programs. As we are dealing with Eiffel this can be a bit harder to implement, but some tools can still be used.

Advantages

  • has tools to translate
  • has tools to merge new strings into the actual catalog
  • independent from the platform

Drawbacks

  • uses only PO files (we should write a parser)
  • has no runtime library for Eiffel

KBabel

This is the tool used by the KDE community to translate the interface, it works with gettext and PO files. From their [1]website: "KBabel is a set of tools for editing and managing gettext PO files. Main part is a powerful and comfortable PO file editor which features full navigation capabilities, full editing functionality, possibility to search for translations in different dictionaries, spell and syntax checking, showing diffs and many more. Also included is a "Catalog Manager", a file manager view which helps keeping an overview of PO files. Last but not least it includes a standalone dictionary application as an additional possibility to access KBabel's powerful dictionaries. KBabel will help you to translate fast and also keep consistent translations."

Writing our own tools

That could be a good idea to write our own tools to do these tasks, in particular for a distributed translation (everybody can help on internet). With this I mean a little website that allows us to do the actual translation directly via the web, and it should automatically create the new version of the language file to be downloaded from all the users.

Another thing that this tool can do for us is scanning the entire source code looking for new translations to be done, and propose them to the users... can be interesting because we than only have to click on a link and all the work (not the translations) is done for us.

Advantages

  • independent from the architecture
  • independent from the language file format

Drawbacks

  • can be a lot of work

Problems, Ideas, Further Development

some problems/ideas that may go with the other parts of this project as well:

  • The i18n can be put online as a database that everyone can update (thus helping translation in many more languages)

After the user has chosen a language the entries still untranslated will be displayed so that the user can insert his own version of the translated message There may be the problem of some users who may have fun writing bad, strange, crazy, nonsense sentences, thus a solution is needed since it clearly can't be checked by the project team

  • The main database can be updated as soon as something new for eiffel comes out (by updated here is meant simply adding the new messages, not their translations)
  • A 2nd database can be placed on the user's pc and autoupdate Eiffel and the additional content one may have when needed (when a new version of Eiffel or a new tool is available for example), with this system one doesn't need to download every time a new file containing some information already downloaded before
  • Unicode problem (maybe a collaboration with the Unicode group can help)