Provide a new work flow and documentation for developers to assure that new Ubuntu applications are fully internationalized and "localizable".
With the 8.10 release two new applications were included in the "main" repository component. None of them where internationalized; after the string-freeze deadline both of them have been internationalized, only one has been localized for the 8.10 release, the othe one has been localized but won't be used in 8.10.
There's should be a "blocker" to applications intended for end users (power or basic) that don't comply with "i18n best practices". The "blocker" is provided by a work flow where the new applications are reviewed by developers and by someone from the translation teams following "i18n best practices". If an application does not meet the "i18n best practices" before a deadline, it should be moved outside "main".
The "i18n best practices" is a document written within/for this specification where it will be explained what are i18n and l10n and what is the best way to internationalize an application with code snippets and examples.
- Alice is developing a new application and all the world want her application to be in Ubuntu «'cause it rocks»! She asks in the developer mailing list to include her application in the upcoming version of Ubuntu: the developers and the translation team are enthusiastic about this application and ask her to comply with the "i18n best practices" in order for her application to be "localizable". She works night and day and provide a fully internationalized application. The application is in "main", translators are happy translating this wonderful application, all the world rejoice and Alice is a step closer to conquer the world.
- Angelina is also developing a new application and asks in the developer mailing list to include her work. The developers and the translation team reviewing the application ask her to comply to the "i18n best practices", but Angelina unfortunately doesn't have enough free time to work on the i18n of her program before the deadline for the upcoming release. The application will be moved in "universe" until she can work out the i18n aspects, translators are happy (they always are!) because they don't have one more application to translate, Angelina is not a step closer to conquer the world but she wins an Oscar for best actress.
- Discuss this specification and the actual work flow and reach an agreement with developers, maintainers, release manager and with all the team leaders involved in the development process about the work flow to follow and the deadline to set.
Decide where to store the necessary documentation: online vs. offline (wiki vs. DocBook).
- Write the documentation.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.