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
Translation of the Release Notes was painful They are coming late and are moving.
Could the Release Notes be moved to the wiki?
- That would increase the number of people involved for updating the Release
- Risk of vandalism
- That might be interesting to gather information from the users.
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
- do we profit from the similarities
- do the teams know / share with other teams
E.g. scripts to reuse the Spanish translation when translating in Catalan.
Advertise more debian-l10n-english. It is in the developer reference. ITP should be reviewed more?
- Translation of "close" languages
DDTP => ask Felipe & Michael & Andreas (UDD / Pure Blend)
- Release schedule
- raise bugs against original strings
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
=> Add it in the coordinator interface => DONE: Nicolas file a bug + usertag 538774
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)
=> this is usually coming from a template. It would be better to
- translate the template. Identify those packages as special. Introduce placeables for these package
=> DONE: Nicolas raise a bug 538775
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)
=> Add a mass-fix button with an approval from the coordinator add a list of packages which could require a mass-fix => Why not an automatic translation?
=> do it later?
=> discuss on debian-i18n the different options. => DONE: Nicolas raise a bug 538779
DDTP identify paragraphs per checksum. DDTP could replace the old translations automatically
TODO: customization per team
=> Add the customization to the coordinator page => polishing needed in the coordinator page => DONE: Nicolas raise a bug 538773
TODO: Add a coordinator area
=> Need approval from translation team who are the coordinators
- then ask debian-i18n then a churro admin define the language coordinators
=> DONE: Nicolas raise a bug 538768
TODO: When a translation is performed, add a button to link to the packages (in the queue) with an identical paragraph
=> There is already a link somewhere, it just need to be added => DONE: Nicolas raise a bug 538777
- TODO: Translate per Blend? (for very specific description like debian med)
- QA in DDTP
- translation of "similar" languages
- DDTP Goals
- per paragraph translation to solve the "common paragraph" issue
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)
-> but bottleneck will be the coordinator
Other solution: coordinator validate -> but coordinator will be the coordinator
coordinator page: show the conflicted translations and the coordinator choose a translation.
- non automatic update
- manual by coordinator
- show the alternatives for a translation.
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
- HTTP links
- wordlist check
Use the wiki for input data from users for the Release Notes
(iki)wiki and i18n
Jonas wrote a i18n plugin:
- allows the use of po files for MARKDOWN wiki markup through po4a.
- editing a translated page will show raw po file: search for a web PO editor ?
no interest in writting a i18n plugin for MoinMoin given its too moving code
- jonas will try to output docbook XML from markdown
Install an instance of ikiwiki?
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