Created: 24/04/05 by MarkShuttleworth
UduSessions: 9 (5 discussion, 4 drafting)
OpenOffice.org presents us with a number of challenges with regard to localisation. This spec is an overview of the specifications related to OpenOffice.org localisation. We need to have each of these discussions and flesh out a set of specifications defining work to be done.
Issues to consider:
OpenOfficeRosetta - how do we integrate OpenOffice into Rosetta?
Can we convert OpenOffice to the gettext internationalization format?
Identify why OpenOffice localisation files are so HUGE and see if we can fix it, it hurts us.
OpenOffice is by far the most commonly used open source office application. It's extremely important to Ubuntu and the free software movement. To the extent that we can improve the localisation of OpenOffice using Rosetta we will be accelerating the spread of free software in the home and office environments.
Scope and Use Cases
- Update OOo2 snapshot and build with g++-4.0, once that is the default for breezy.
- Assume we are able to get OOo2 into breezy. Have a status of the buildability with free tools at the end of June.
- Add build support to build with --enable-languages=ALL. Currently we build for one language only.
- Adding a new language
- Find out, if source changes are needed to add a new language (besides the translation strings) (doko)
- If changes to the source are required, we are not able to add a new language after release.
- Handling updates from Rosetta
- Export all po files from Rosetta.
- Generate the new GSI file (one for each language), the old GSI files need to be available to do that, we will have them available from the extract phase on build time.
- Put the GSI files in the debian directory; at build time, build the localization tools, then merge the GSI files, then
- build the package. Storing the diffs for each translation provokes merge and patch conflicts.
- This procedure doesn't work for OOo1, the localization tools have bugs, the .src/.hrc files need manual fixing after the GSI import.
- How to build the language debs only, without building the architecture dependent packages: Do not directly build the l10n packages from the OOo source, but store the files stored in the temporary installation directories to a separate source package. This way we are able to update the translations after the release.
- Handling translation strings in Rosetta?
- Problem: Split/divide the huge number of translations in Rosetta and present them in chunks for translators. The idea is to implement a way to select subsets of message sets easily so different translators can work in the same .po file at the same time without getting collisions each other and as they were working on different .po files.
- Rosetta updates for each build
- Build the localization subproject
- Import (localize -i) all existing GSI files (created by earlier Rosetta exports and conversion scripts)
- build the package
- Export (localize -e) all languages, apply conversion scripts, import them into Rosetta
- Add spell checking, hyphenation patterns and thesaurus (if it exists) for supported languages.
- Check how to feed translations into the upstream sources (or ximian-ooo repository).
Data Preservation and Migration
User Interface Requirements
We need to look at the current state of OOo2, before reliably scheduling more work.
- Describe localization process (adding a new language) (doko). Done, needs to be added to the wiki after the conference. See some kind of explanation at (add image ..)
- Describe localization update process / interaction with Rosetta
- Where to keep old GSI file, which are needed to generate the new GSI files and the updated po files.
- Translation of OOo help. It doesn't make sense to split up a document in single strings/messages in po.
- We want to use only one .pot file instead of multiple .pot files but we are not sure that's possible atm, so that should be checked.