Re: I18N spam part II -- "reviewed" po files
- From: Fatih Demir <kabalak gmx net>
- To: gnome-i18n gnome org
- Cc: GNOME Turk listesi <gnome-turk gnome org>
- Subject: Re: I18N spam part II -- "reviewed" po files
- Date: 22 Jul 2001 12:10:05 +0200
On 22 Jul 2001 16:53:08 +0800, R.I.P. Deaddog wrote:
> > * It's bureaucratic and doesn't fit well with the volunteer style of
> > projects that most free software projects are, and I also think it puts
> > pressure on the reviewer when in fact the translator should be
> > responsible for his translation. What I mean is that there is not many
> > people that would want to be held responsible for other people's
> > translations, I think.
> > I think we have an advantage in our informal system that way - anybody can
> > comment, and anybody does. In many cases there is two or three people
> > looking through the translation. I doubt that we would have that if people
> > were required to do an offical, formal review.
>
> Isn't this reviewer tag supposed to be optional, not a mandatory one?
It's purely optional, I'm not in a position to make anything mandatory.
Neither do I develop gettext, nor do I work for some bigger companies..
> If
> people don't want their name show up in reviewer field, just don't fill
> it. Fatih, is it supposed to work that way?
Yes, purely optional. In gtranslator there would have been a special
"Open for Review" opening modus which would cause the reviewer tags of
the header to be filled up..
But after some thinking I guess, there's no need for such review
extension/stuff, the language teams should handle this on their local
level. Right..
> > * The "mark-every-message-as-reviewed" system adds too much overhead to
> > files. Po files can be insanely big as they are, we don't have add
> > more clutter to every message. Also, the tools don't support it - I don't
> > think the reviewd-by comments will survive many translation memory
> > updates, merges, etc. Or am I wrong?
They wouldn't survive some other tools, right .-P
> I can't agree more, since usually the whole translation is reviewed by one
> person only, sometimes two and I guess three is very rare.
... if it's reviewed at all..
> > * The "mark-whole-file-as-reviewed" system doen't work in a rapidly moving
> > project like GNOME, I think. Some translations I update daily, and
> > messages are thus added and changed daily, making the effective lifetime
> > for a review to one day or so...
>
> Again, is the "Last-translator" field having similar sense as
> "Reviewer"?
No. In my understanding and the original reason for thinking about such
stuff (I did dump the idea to be honest, no need to support/do such
stuff AFAIS).
The reviewer just reads the translations and makes slow corrections, it
_shouldn#t be the case that a reviewer ends up with being the last
translator...
> And I suppose other translations can't necessary mean to
> update as often as they can. If it is said that reviewing can be out date
> one or two days, then translations can also be outdate one or 2 days
> later (for other langs).
> So I guess something like "X-Last-Reviewer:" in addition to
> "PO-Review-Date:" so that one can determine if the review is outdated, and
> we needn't add all reviewers since pre-historic time.
Yes, would have been logical. And I think there should be only the last
reviewer mentioned.
The previous translators should be (by "good style") mentioned, listed
up in header comment, but I don't think there's a reason to do th saem
fro reviewers..
The last reviewer would have been enough..
> > In short, I think this has to be solved by more informal reviews and
> > getting the teams to really use their mailing lists, rather than inventing
> > some formal review syntax, that is rather unlikely to be supported by
> > gettext & co anytime soon.
> It's true that informal reviewing is enough (that's my experience, not
> necessary others), but inserting that reviewing information isn't bad.
Yes, but if there's no/almost no good feedback about it, I won't
think/do anything about it. Was just an idea for commonizing something
which should be done but anyway...
The header comments keep growing..
> Other applications can ignore that tag instead of segfault or refusing to
> start, right? Don't think it's very harmful even if it's useless.
Ehem, I can't speak for them, but for KBabel it shouldn't matter as it
doesn't parse the header on a "higher" level. For gnopo etc. it would
possibly be too much and they'd be cut it off. Dunno.
--
kabalak / kabalak kabalak net / Fatih Demir
`-GNOME / ICQ:64241161 / GSM: +491749787080
`-Editor / vim
`-Filemanager / VFU
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]