Re: Notes from the Debconf6 2nd BOF about i18n infrastructure
Hello,
I'm using my last minutes of network access before the end of May to send
the notes I took during the second BOF about the Debian I18N
infrastructure.
Just a remainder: during the BOF we thought it would be nice to:
* start a thread in debian-legal about the translation licence.
* contact the release coordinators to add "have DDTP translations in the
official archive" as a release goal.
Best Regards,
--
Your secretary
Some notes from the second i18n BOF
* Another kind of users: institutions
=> they should fit in the Visitor category
* 2 kind of team coordinators: per project/per language
* How to provide support to the end users
=> language packets
* The final users needs to report bugs
* Administrators tasks
manage authorizations and ownership
manages users
remove inactive users
some tasks could be delegated
* Translators need priorities
* Several owner / group of owner for a translation (e.g. Dutch's d-i)
* Need for glossary/glossary enforcement
associate multiple translations for a word, display them to the translator
When an interface is used, it could looks like a 3 boxes window:
|------------------------------|-----------------|
| English English English | Glossary |
| English English | Word1 |
|------------------------------| Tranlation1 |
| Translation Translation | Tranlation2 |
| Translation | |
|------------------------------|-----------------|
* The maintainers need notification (but send them only if they want it)
* When does the notification has to be sent?
Every commit
When the translator tells "My translation is OK"
* Maintainers need to increese the priority (I'm going to release), but also to decrease the priority ("I'm currently working on it")
* Some translation teams may need a stable version
=> use of branches
(for all teams?, only at some point in time?)
* If there are some branches, we need a "merge" feature
* Statistics for testing is something good, even if we cannot translate testing.
* Reiewer needs
=> to be done
* team coordinator may need to set some goals, and see/show if the goal is achieved
* This may require meta-projects (d-i level 1,...)
* Users should be able to propose some changes
* The architecture should support any kind of documents (not only PO)
[note ffrom another BOF, I don't know if this will be the case in the first implementation]
* the release coordinator must be contacted to get some help from the FTP master to get the DDTP translation in the official archive.
It should be added to their release goal.
Some meta-data may be needed for each strings (e.g. string size constrainsts)
* The Wiki has to be used for the specs
Describe goals and details
[Note: I won't have time to put this document in the wiki]
[Note: at this time in the BOF, the Wordforge wiki with the specifications was not known]
* Multiple instance of the infrastructure (e.g. an instance for a language team)
=> need for communication between these instances
This can be important for country were the link with other countries is expensive
* Offline tools are also very important
* Offline and Online reviews
* Rosetta has/will have an XML RPC interface
* Licence of the translations?
This is an issue. A thread has to be started on debian-legal
Some notes taken during Javier's presentation about Wordforge
* Glossary enforcement
* a problem in PO: the reviewers do not know what messages need to be reviewed
=> in the PO processes, we send patches for the review of big POs
=> this is possible in XLIFF
* TM (Translation Memories) need small sentences.
* There is a sentence separator in the XLIFF strings to help reusing strings
* The XLIFF specification is stable
[Note: IIRC, the current spec is 1.1, a 2.0 will come with only little changes]
* An XLIFF file contains many type of content (the translatable strings, a glossary, a TM, results of tests).
=> XLIFF is(/will be) used as the backend of Wordforge
XLIFF is very suitable for an offline translation (the users will have the glossary terms they need)
* Pootle will be distributed (communication between multiple instances)
(A server could receive POT, and send PO to the other isntances)
Reply to: