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

[Kenneth Nielsen <k nielsen81 gmail com>]

Hi Johannes

2011/4/7 Johannes Schmid <jhs jsschmid de>:
> 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).

Yes, that is the idea. The assumption is that all modules on one page
in damned lies has to adhere to the same set of rules (whatever they
may be). So either they are required to follow GNOME release schedule
or they are not. If they are not _required_ then they inform DL (in
one way or another) whether they still intend on following the GNOME
release schedule (in which case the information can be autogenerated),
and if they don't, they provide a date, when they have one. It was
never the idea that all modules in DL had to have this information, if
there is no release planned, then they don't set the date and we will
know that it is lower priority. Then when they decide to plan a
release, they set the date and we start translating.

About the list, I think it is crucial that it is in DL since, as a
translator, that is the center of my whole world ;). The information
needs to be right there next to the number of strings needing to be
updated.

Concerning how to change the release date for your module, I think it
is important that it is something that developers and documenters can
do without any "middle men". I'm a low tech kind of guy, so I would
just ask them to put this information in a file somewhere in the
source tree and have DL parse it, maybe there is a better way, but it
has to be easy and direct.

> 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".

The documenters know how up to date their documentation is. So the
only things that is required is, that when they bring the
documentation up to par with a certain release of to the state of
current trunk, then they write down that release of the date in a
file, that DL then parses. Same thing for marking it as DO NOT
TRANSLATE, when you start rewriting the documentation from scratch,
write it in that magical file and the information will be on DL.

Regards Kenneth