Re: Adding information column to DL with proposed release dates and documentation state

[Shaun McCance <shaunm gnome org>]

On Fri, 2011-04-08 at 08:55 +0200, Gil Forcada wrote:
> El dj 07 de 04 de 2011 a les 17:01 +0200, en/na Johannes Schmid va
> escriure:
> > Hi!
> > 
> > > At this point this it is just an idea and I am very much looking for feedback.
> > > Would this be helpful?
> > > Will developers play along?
> > > Will this be acceptable within the design goals of Damned Lies (Claude)?
> > > Should the information in this columns be what I wrote, or is there
> > > something else that would be more helpful?
> > 
> > As there are still "rules to be defined" for the applications included,
> > this is difficult to tell. However, I think at least a list of release
> > dates would be helpful as long as it can be generated automatically from
> > GNOME releases and only those modules that have other dates would need
> > to update them accordingly (which could send a mail to gnome-i18n).
> > 
> > The documentation part seems difficult to me because it is always hard
> > to tell how up-to-date documentation is. But it would be nice to have a
> > marker that says "Don't translated, this is outdated/being updated".
> 
> Quoting from Shaun McCance:
> 
> I've just added the following to all the pages in gnome-help:
> 
>   <revision pkgversion="3.0" version="3.0.1"
>    date="2011-04-06" status="outdated"/>
> 
> 
> So, no, if we put a Mallard parser on D-L we could know the outdated
> status of mallard documents.
> 
> Maybe even the mallard2po (or whichever script transforms mallard to po
> files) could also add some metadata to the strings that are inside a
> document with that header.
> 
> Shaun, could you explain it further?

Right, at least for the gnome-help, the documentation team made
extensive use of the <revision> element, and we'll use it even
more (and probably refine our use of it) in the future. The info
in the <revision> element is probably useful to you all, because
it can help you prioritize.

The thing is, the revision marker is per-page. So it's not an
all-or-nothing on a single document kind of thing. That has its
ups and its downs for translators, I think. But an up is that
we could mark strings as stable or not in the PO files.

By the way, much of this information is available on Blip:

http://blip.blip-monitor.com/

So one of the projects I've been working on is a replacement
for xml2po called ITS Tool.

http://gitorious.org/itstool

It's the same idea. Strings are extracted from XML files and
put into PO files, then merged back. But it does everything
according to rules from the W3C Internationalization Tag Set,
plus some extension rules to support features we need. I can
add a rule to put a comment or something on each string that
says if that string is stable or not. I don't know if there's
a standard PO marker for that.

Actually, if any translators have a little free time (I know,
who has free time?), I wouldn't mind people trying it out and
giving some feedback.

--
Shaun