Hoi,
From the point of view of the internationalisation and localisation there
are two states.
- the English message is stable and fits the requirements of i18n; it is a meaningful translatable message with constructs like gender and plural as needed - The English message is stable and does not fit the requirements of i18n.
When the message does not fit the requirements, it is from an internationalisation point of view obviously a bug. This is typically fixed by the developers at translatewiki.net and has an effect on all existing localisations; they are FUZZYd. From the point of view of the development of code such bug fixes are transparent.
The LocalisationUpdate process, functionality that was created to bring localisations to an installed environment in a timely manner is based on the English message being exactly the same. In translatewiki.net we know about messages that exist only in previous releases and they are still available for localisation. As a result releases are very much external to the localisation effort. Localisation work is motivated by making a difference on a live environment.
In order to prevent issues with localisation during the shake down period of development, it is best to release code early and often. This will make new or changed messages visible to the developers at translatewiki.net and this enables them to adjust messages for i18n purposes when needed.
Bug 28191 was added today and it seeks to decrease the time from localisation to implementation. At this time the implementation of newly localised messages is done with a cron job, I understand from your description that it might technically be possible to push localisations out whenever. Practically this will happen only once the quality assurance processes at translatewiki.net have been completed.
I hope this helps. Thanks, GerardM
On 23 March 2011 02:27, Ashar Voultoiz hashar+wmf@free.fr wrote:
On 22/03/11 20:26, Brion Vibber wrote:
I've started collecting some notes on issues that need to be considered
for
a potential git migration:
http://www.mediawiki.org/wiki/Git_migration_issues
I'm paying particular attention to the localization workflow thing. Note that TranslateWiki's been working on StatusNet's git repository for some time; git itself isn't a particular problem. But changing the layout of repositories could indeed change how some things need to be done, and we need to make sure we know how to solve whichever problems come up.
I think it's pretty likely that we can work those problems out --
nothing's
set in stone yet, and there's plenty of opportunity to experiment with
some
sample layouts first!
Tools are almost never an issue. We could as well use Bugzilla as a patch/review queue and have ONE release manager to apply them in a CVS tree. I have seen developers using MS Word to track code, they even managed to merge their code this way.
The issue we have is a proper workflow and, I believe, the lack of a roadmap.
Do we really need all the language messages in core? They are probably "useless" for day to day code hacking. Most developers probably use the English messages only anyway. The only things we have to do is to fill up the Messages.inc metadata file, and the English message. Nowadays, I do not even bother to translate my own messages to my native language (which is French).
So, to me, messages serves no need for the developers. They are only useful for live site and MediaWiki releases.
For the live site, we could just pull messages from whatever system is used (gettext .po, rosetta, git, ftp site). This can be done every week, day or hour.
Then comes the need to release a MediaWiki release. This mean you have to sync both projects (code + l10n) and this is not possible while you keep having new messages added in MediaWiki or messages parameters being changed.
That is what I meant by a workflow. We have actors, tasks and responsibilities and eventually end up with a product.
I have said it already: we need a rough roadmap to release a new version. One of the first steps would be:
- obviously 'no new features' step . Followed by...
- 'no new UI messages'
- 'no parameter changes'
- 'no messages changes'
This will give time to translators to finish up the messages translations for the release.
The lack of roadmap for 1.18 is probably the same cause that makes our code review queue filled again. It looks a bit like a wiki sandbox, some code (myself included) should never have been sent to trunk.
To conclude, the good point, is that we have 1.17 feature frozen, deployed on live site and it might even get released before this summer. Given the situation back in September 2010: this is a huge accomplishment :-)
-- Ashar "hashar" Voultoiz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l