Difference between revisions of "Internationalization"
m (→M3: May ???) |
m (→M3: May ???) |
||
| Line 38: | Line 38: | ||
** globality: how to implement, the object should be shared between all modules | ** globality: how to implement, the object should be shared between all modules | ||
** collaborate with the [[Vision2_and_Unicode]] team | ** collaborate with the [[Vision2_and_Unicode]] team | ||
| + | :Take a look at [[Talk:Internationalization/translation function]] for a possible structure of the whole. [[User:Trosim|Trosim]] 12:09, 22 May 2006 (CEST) | ||
*Test unicode support in Vision2 ''(Ivano)'' | *Test unicode support in Vision2 ''(Ivano)'' | ||
* compile a [[Internationalization/features list|list of basic features]] to provide (e.g. date/time format, system locale) ''[deferred]'' | * compile a [[Internationalization/features list|list of basic features]] to provide (e.g. date/time format, system locale) ''[deferred]'' | ||
Revision as of 01:09, 22 May 2006
Contents
Overview
"Many [people] would simply love seeing their computer screen showing a lot less of English, and far more of their own language." -- gettext doc
Our aim is not only to provide a framework to ease the translation of Eiffel-written applications, allowing the user to chose his/her preferred language at runtime, but also to let the developer access information and formats based on users' locale.
What is internationalisation?
The first thing that comes to mind is translation. But internationalisation isn't restricted to enabling translation: it includes making it possible to localise notations (time, date, numbers), measures, paper size, and much more.
What should we achieve?
- Applications should be able to load localized strings at runtime and be provided with localized format strings (e.g date format).
- Developers can use tools that automagically extract strings from source code and can try to get them translated in a file to distribute along with the application.
- Users will still be unhappy and get depressed but in their own language, which we can all agree is a significant step forward.
Who should do the achieving?
It is clear that our Glorious Leader should be credited with any achieving. However he will have to delegate things somewhat, as he is is not Stakhanov. We can probably divide the project into the following parts, modulo preliminary research:
This should be probably be completed after we have got past M1
Milestones
M2: May 5
- feasibility: look at string classes (unicode and not) and how strings are used in EiffelStudio (creation, composition) (Ivano, Carlo, Leo, Hong)
- file format: compare existing file formats for dictionaries (Etienne, Andreas)
- tool evaluation: list and compare existing translation tools (Christian, Martino)
M3: May ???
- write an initial .po to start translating and have a .mo for testing (Leo, Carlo)
- mo parser: extract translated stings from .mo files (Etienne, Martino)
- code parser: extract strings to be translated from source code and generate .po file
- translation function: map hard-coded strings to translated strings
- find a solution with templates
- globality: how to implement, the object should be shared between all modules
- collaborate with the Vision2_and_Unicode team
- Take a look at Talk:Internationalization/translation function for a possible structure of the whole. Trosim 12:09, 22 May 2006 (CEST)
- Test unicode support in Vision2 (Ivano)
- compile a list of basic features to provide (e.g. date/time format, system locale) [deferred]
Possible future developments
- collaborate with the ESWizard team. Create wizards for programms with translation facilities.
Relevant Links
What other people have done
howto for internationalisation of KDE programs
another KDE howto (doesn't Gnome do any internationalisation?)
Team
Everyone interested in this project is welcome to join our mailinglist es-i18n@origo.ethz.ch
