Added section on docs in general and recommendations about them, and other bits
← Revision 5 as of 2009-03-16 03:30:47
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 56:||Line 56:|
|* The release specific pages are obvious the parts below the /releases/RELEASENAME/ directory, and all files that contain the <if-stable-release> switches (which should be in all relevant pages by now). Most of them should be properly prepared already so it can be done well ahead of time.|
This page contains data about releases and planning for i18n tasks.
It intents to provide best practices and recommendations for the planning of the next releases.
- Announced for RC1 on 2008.08.29, for 23 days
- Daily statistics
Followed by call to focus on level > 1
When was it finished?
There has been an RC2, could we have been able to update translations between RC1 and RC2?
This applies to the Installation Guide, the Release Guide, the Release Announcement, probably other docs, and (where appropriate) webpages. The Installation Guide currently serves as a model for other doc translations.
- Ensure we have a webpage for translation status which is updated immediately from SVN, if possible (if not, updated as often as possible). When changes are coming in often, and the deadline is close, this helps us keep track (and not miss changes).
- Additionally, would it be difficult to set up email notifications of changes to docs to which that particular translator or language team is subscribed? This works extremely well for the Debian Installer files. We also currently get an email notification of the status of the build for the Installation Guide. Translators and teams can have the option to subscribe to these notifications. I (Clytie) personally find email notifications a big time-saver, and projects supplying these notifications get higher priority from me.
- Well-timed reminders on the debian-i18n list are really useful for translators who can't always keep up with the overall picture for one reason or other. Reminders of the deadline, importance and development status of a doc. are particularly useful. The Release Announcement was handled well this year in that regard.
- Use subject-line tags on debian-i18n to help resource-low translators keep up with key emails. Examples: DOC, GUIDE, NOTES, ANNOUNCE, WEB, CALL. When I (Clytie) don't have time to read debian-i18n, I filter the "Please translate" deb18n emails into a separate priority mailbox. Tags would enable us to filter out priority mail (e.g. call for translations, please update file) more effectively.
- Call on 2008.10.26, Deadline 2008.11.10, extended to 2008.11.12
- Open for later reviews/updates/new languages?
- Later call for fixing strings in December
- First Call: 2008.10.21
- Second Call: 2009.01.18
String Freeze: 2009.02.09 -> 2009.02.12
- Call 2009.02.12, Deadline 2009.02.14
- Update can be done continuously on the website
Debconf, Package Translations, Native Packages
- This is a continuous effort. There is no time/possibility to update those close to a release.
- Remind about priority of translations ("main" first? key packages?) and debconf availability on Pootle. It's very difficult for resource-low language-teams to complete the whole debconf list, but identifying a key group of files and encouraging its translation would boost morale.
- Update the compendia hosted by Debian, and apply current compendia to all untranslated strings in debconf on Pootle. There is a great deal of repetition in the debconf files, so this can save translators a lot of time. It would also make the task less intimidating, and more "doable" in the bits and pieces of time we have available.
- Also a continuous effort
- Some pages might be Release specific. (Yes: again, remind translators of priority pages. The whole site is enormous, but translating a few key pages would make a big difference to users of that language.)
The release specific pages are obvious the parts below the /releases/RELEASENAME/ directory, and all files that contain the <if-stable-release> switches (which should be in all relevant pages by now). Most of them should be properly prepared already so it can be done well ahead of time.