Session 1

Translation of the wiki

TODO: Ask on debian-i18n who would be willing to translate the wiki.

TODO: Check if we should move content from the wiki to the website, and back

Release Notes

Translation of the Release Notes was painful They are coming late and are moving.

Could the Release Notes be moved to the wiki?

Wiki would provide a document sooner than with the current process.

Lack of translation of the release notes should be release critical. File a critical bug?

Talk to the release notes maintainer / release team Symoon / Nekral: prepare a proposal

Spending Debian money on i18n

Translation parties? See how debian-edu work sessions are working. It works. Organize contests to bring new translators into debian.

Resources needed to teach new translators is important.

Will new comers continue after getting the bounty? (same issue with GSOC)

Feedback from the teams

Assigning task to individuals is difficult

Translation of "close" languages

E.g. scripts to reuse the Spanish translation when translating in Catalan.

Miscellaneous

Advertise more debian-l10n-english. It is in the developer reference. ITP should be reviewed more?

Next meeting

Session2

Working with DDTP

Felipe - Brazilian team - presented the Brazillian Portuguese DDTP translation process

Fetch the package to appear in the "Pending Translation queue" hand work, once a week, per letter

DDTP tries to push per priority Felipe fetch per letter to let translate similar strings at the same time. (because the highest priorities were done)

Translator introduce comments to indicate pending work, reviews There is now a log of the comments

Script to cheat the system to indicate that there were reviews to let the translation being accepted. Could be changed in the database in Churro (shell access needed + knowledge of the database)

Translation/Review does not happen on the mailing list (only translation issues)

TODO: add a button to fetch the next X 'y' letters

Problem for understanding the process for people translating only once (e.g. when they see an error in a translation)

5 people are translating, visiting the web site every day.

TODO: detection of fields in strings (e.g. version in kernel description)

TODO: help finding all the packages which contain a given string (e.g. when a typo is fixed in one package, all packages should be reviewed)

DDTP identify paragraphs per checksum. DDTP could replace the old translations automatically

TODO: customization per team

TODO: Add a coordinator area

Next session

Session3

DDTP

Grisu started working on the implementation of the ideas from last session.

Example: translation of a KDE package. Translation of a second package should not lock again if the common paragraph is not changed.

Info for the coordinator that some changes happened in important package. (important: share a paragraph)

Other solution: coordinator validate -> but coordinator will be the coordinator

coordinator page: show the conflicted translations and the coordinator choose a translation.

3 solutions

decision:

There is an admin page. If you know the URL you get the admin rights. This should be fixed ASAP (bug already raised)

TODO: Jens script to submit translations from a Translation page.

=> add a upload input in the coordinator page => Issue: does not encourage the review process

TODO: Limit access to the mail interface

=> add a checkbox in the coordination page => Team can choose => check if there is an help message for the rejection => or just make suggestions instead of forcing => multiple options

TODO: Rosetta already provide suggestions

=> propose to import Rosetta as translations, not suggestions Ubuntu translations merge the translations * import new translations as suggestions * import new translations as translations * update modified translations as suggestions * update modified translations as translations

QA tool

Next Session

Session4

Use the wiki for input data from users for the Release Notes

(iki)wiki and i18n

Jonas wrote a i18n plugin:

Install an instance of ikiwiki?

Release-notes

Issue: publication

Is branching an issue to be taken into account for the Release Notes? The Release Notes are branched (one for each release), but there are usually no merge between branches.

Conclusion for editing the Release Notes in the Wiki: No for technical reasons. The release notes need to be published using PDF output.

Workflow for release-notes

* To avoid translation rush and wasted energy at last moment, anticipate editing. Example: already announced changes/goals like dash as default, see SqueezeReleaseGoals * RN editors team to subscribe upgrade-reports pseudopackage in PTS