Difference between revisions of "Internationalization/tool evaluation"
(→KTranslator) |
(→Writing our own tools) |
||
(13 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | + | [[Category:Internationalization]] | |
+ | |||
In this section it will be discussed which tool should be taken for the i18n work. | 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 | * Search the source code for strings and other things that needs to be changed | ||
* Create a file containing these results | * Create a file containing these results | ||
* Enable the change of language and format of Eiffel | * Enable the change of language and format of Eiffel | ||
− | + | = Tasks = | |
The tools we should analyse have several tasks: | The tools we should analyse have several tasks: | ||
Line 17: | Line 18: | ||
Here you'll find the advantages and drawbacks of every tool we evaluate. | 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: | 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. | + | This set of tool is funded by the GNU community and is meant to help internationalize the C-Programs (and also C++, ObjectiveC, Pascal, PO, Python, Lisp, EmacsLisp, librep, Java, awk, YCP, Tcl, RST, Glade). As we are dealing with Eiffel this can be a bit harder to implement, but some tools can still be used. |
Advantages | Advantages | ||
Line 31: | Line 32: | ||
* has no runtime library for Eiffel | * has no runtime library for Eiffel | ||
− | + | === poEdit === | |
Yet another PO catalog editor. | Yet another PO catalog editor. | ||
Line 43: | Line 44: | ||
[[http://www.poedit.org/ Visit the website for more information.]] | [[http://www.poedit.org/ Visit the website for more information.]] | ||
− | + | === KBabel === | |
This is the tool used by the KDE community to translate the interface, it works with gettext and PO files. | This is the tool used by the KDE community to translate the interface, it works with gettext and PO files. | ||
From their [http://kbabel.kde.org/ website]: | From their [http://kbabel.kde.org/ website]: | ||
Line 123: | Line 124: | ||
− | + | === KTranslator === | |
This tool helps the translation of single words, independently from the used application. | This tool helps the translation of single words, independently from the used application. | ||
Line 136: | Line 137: | ||
[http://ktranslator.sourceforge.net/index.html More] | [http://ktranslator.sourceforge.net/index.html More] | ||
− | + | === Other tools to watch === | |
* xgettext | * xgettext | ||
* poxml (Definition: tools for using PO-files to translate DocBook XML files This is a collection of tools that facilitate translating DocBook XML files using gettext message files (PO-files).) | * poxml (Definition: tools for using PO-files to translate DocBook XML files This is a collection of tools that facilitate translating DocBook XML files using gettext message files (PO-files).) | ||
* [http://po4a.alioth.debian.org/ po4a] (The po4a (po for anything) project goal is to ease translations (and more interestingly, the maintenance of translations) using gettext tools on areas where they were not expected like documentation.) | * [http://po4a.alioth.debian.org/ po4a] (The po4a (po for anything) project goal is to ease translations (and more interestingly, the maintenance of translations) using gettext tools on areas where they were not expected like documentation.) | ||
* xml2po | * xml2po | ||
− | * [http://nlso | + | * [http://sourceforge.net/projects/nlso NLSO] (for Windows) volunteers needed to rewrite this for Lazarus IDE, Could also be achieved using Eiffel, this would also open it up to Apple OS & Linux,[http://comchatter.com/contact.php Contact Ivan via this form for more info] |
+ | * [http://sourceforge.net/projects/nlso-web NLSO-WEB] (for Web design) | ||
+ | * [http://comchatter.com/nlso ComChatter.com/nlso] (the new home of nlso), a site built using NLSO principles | ||
+ | * Kartouche | ||
− | + | === Conclusions === | |
− | + | == 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). | 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. | 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. | ||
Line 156: | Line 160: | ||
Drawbacks | Drawbacks | ||
* can be a lot of work | * can be a lot of work | ||
+ | Efficient use of time would be to combine NLSO-WEB for web interface with a custom written module for source code/po file translation which could be executed on the client's computer, anybody interested in putting such a project together? [http://comchatter.com/contact.php Contact Ivan via this link] | ||
− | + | = Problems, Ideas, Further Development = | |
some problems/ideas that may go with the other parts of this project as well: | 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) | * The i18n can be put online as a database that everyone can update (thus helping translation in many more languages) | ||
Line 165: | Line 170: | ||
* 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 | * 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) | * Unicode problem (maybe a collaboration with the Unicode group can help) | ||
+ | |||
+ | * NLSO-WEB already supports UTF-8 format & presents it correctly | ||
+ | * NLSO-WEB had the database of language data online and it can be updated by authorized users via the browser | ||
+ | * NLSO-WEB has autodetection of the client browser language settings and uses primary / alternate langauge policy to maximize the usability of the site | ||
+ | * NLSO-WEB can be easily introduced to an existing website which uses PHP & Mysql, so much of what's suggested here is already available in one library, it also includes IP to country system and considerable Geo-Data | ||
+ | |||
+ | Using NLSO-WEB to provide a back-end & support pages combined with a client module is the best way to create applications that share translations, then localized versions could become a thing of the past |
Latest revision as of 10:54, 14 March 2008
In this section it will be discussed which tool should be taken for the i18n work.
Contents
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 (and also C++, ObjectiveC, Pascal, PO, Python, Lisp, EmacsLisp, librep, Java, awk, YCP, Tcl, RST, Glade). 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
poEdit
Yet another PO catalog editor.
Advantages
- has tools to translate
- independent from the platform
Drawbacks
- uses only PO files (we should write a parser)
- has no runtime library for Eiffel
[Visit the website for more information.]
KBabel
This is the tool used by the KDE community to translate the interface, it works with gettext and PO files. From their 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."
Features of the translation tool:
- Support for GNU gettext PO files (including plural forms) and Qt Linguist catalogs
- Experimental support for XLIFF 1.0 format
- Support for multiple translation projects
- Capability to open multiple files (or multiple views of the same file)
- Full editing functionality, accessible through the customizable graphic user interface as well as through user definable keyboard shortcuts
- Powerful spell checking functionality
- Capability to show diffs to older messages
- Full navigation capabilities (such as go to next fuzzy or untranslated string)
- Capability to save and read files in unicode encoding (utf-8)
- Unlimited undo capability
- Syntax highlighting
- Automatic file header updates
- Automatic change of "fuzzy" status of translated messages
- Support for easy insertion of tags and URLs
- Validation and highlighting of tags and XML entities
- A plugin framework for dictionaries, such as po compendium files, for consistency checks or translation suggestions
- A "rough translation" function to initialize untranslated messages with suggestion from a dictionary
- Automatic syntax check with msgfmt when saving and if an error occured easy navigation to messages, which contain errors
- Full Drag & Drop - support
- Configurable fonts for message editor
- Various methods to "see" whitespaces at end of lines
- Various methods to check consistency of translated messages, like comparing printf and Qt arguments in msgid and msgstr
- Quick overview over context in the po file
- Showing source code by references in message comments
- Sending the file using email
- Bookmarks for messages in a file
- Character selection tool integration
- A plugin framework for validation tools for consistency checks
Features of the Catalog Manager:
- File manager view for KDE's l10n module (or similarly structured) directories, which shows the present status of all PO files: if they are in need of a revision or not, how many fuzzies and untranslated strings are included etc. This view is always automatically updated and reflects all changes done to the files, including changes by programs other than KBabel.
- Integrated basic CVS and SVN support
- Various file open mechanisms for editing in KBabel: use Drag & Drop, double click, keyboard or context menu
- "Mark files" function (e.g. to identify POs that are in the responsibility of other translators)
- Powerful navigation using PO file statistics
- Automatic comparisons and statistics of POT and PO files for a quick overview which and how many files are translated (or not) and which files may be obsolete
- Syntax check (msgfmt --statistics) for existing files to control if the translated files will compile and, accordingly, work when distributed
- Free configurable commands, that can be executed from the Catalog Manager's context menu.
- Search/Replace functions in multiple files at once.
- Spellchecking of multiple files at once.
- Sending number of files using email.
- Doing "rough translation" for multiple files at once.
Notes
- under GNU GPL
- part of the kdesdk module
- it also has KBabelDict, plugin-based dictionaries (web-based but can be downloaded as a plain txt file), needs some Perl modules.
- runs only on linux
Info from the official website of KBabel
[click here for more]
On their website infos about Kartouche, a web-based php tool to help translation, is also available.
From the infos available about this tool it looks like it's ideal to reach our goal, it has all we need and more.
Advantages:
- Nice and easy to use interface
- Helps A LOT the translator
- Tool supported by the KBabel community
- GNU GPL
- Supports unicode
- Set of dictionaries
Drawbacks:
- Runs on Linux systems only
- May need some work to adapt it for Eiffel
KTranslator
This tool helps the translation of single words, independently from the used application.
Advantages:
- Application independant, used while running the program
Drawbacks:
- Uses popups to display the translation of the word
- It works exclusively with dictionaries
- It isn't really a tool that can do big work of translation
Other tools to watch
- xgettext
- poxml (Definition: tools for using PO-files to translate DocBook XML files This is a collection of tools that facilitate translating DocBook XML files using gettext message files (PO-files).)
- po4a (The po4a (po for anything) project goal is to ease translations (and more interestingly, the maintenance of translations) using gettext tools on areas where they were not expected like documentation.)
- xml2po
- NLSO (for Windows) volunteers needed to rewrite this for Lazarus IDE, Could also be achieved using Eiffel, this would also open it up to Apple OS & Linux,Contact Ivan via this form for more info
- NLSO-WEB (for Web design)
- ComChatter.com/nlso (the new home of nlso), a site built using NLSO principles
- Kartouche
Conclusions
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
Efficient use of time would be to combine NLSO-WEB for web interface with a custom written module for source code/po file translation which could be executed on the client's computer, anybody interested in putting such a project together? Contact Ivan via this link
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)
- NLSO-WEB already supports UTF-8 format & presents it correctly
- NLSO-WEB had the database of language data online and it can be updated by authorized users via the browser
- NLSO-WEB has autodetection of the client browser language settings and uses primary / alternate langauge policy to maximize the usability of the site
- NLSO-WEB can be easily introduced to an existing website which uses PHP & Mysql, so much of what's suggested here is already available in one library, it also includes IP to country system and considerable Geo-Data
Using NLSO-WEB to provide a back-end & support pages combined with a client module is the best way to create applications that share translations, then localized versions could become a thing of the past