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+...@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
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
