[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: kbabel, cvs and many translators
From:       Logi Ragnarsson <logir () logi ! org>
Date:       2001-01-07 11:52:45
[Download RAW message or body]

Matthias Kiefer:

> Am Samstag,  6. Januar 2001 22:59 schrieb Logi Ragnarsson:
> > In fact, given CVS, these header files serve no purpose. This information
> > is available in much more detail in the cvs repository and can be seen in
> > the cvsweb thingy.
>
> No, this is not really true. With cvs you can see, who commited the file
> and when, but you can not see, who actually translated it.

True, but it could be put in the comment. I.e. I receive a bunch of updated 
files and I commit with the name of the translator as the comment to cvs 
commit.

> > Wouldn't it be a good idea to at least have a setting to make these
> > fields empty instead of updating them with real information?
>
> Why can't you just deactivate the update of these fields? You can do this,
> in section "Save->Fields to update" in KBabel's preferences dialog.

I can. I just didn't notice. This is exactly what I was asking for :-)

> But in general I don't think, it's a good idea to leave this information
> empty, since it belongs to the po file format. I for example deactivate
> updating of this field when doing some small corrections in files of
> others, because of the reason you said and because I don't want to be
> listed as last translator when only fixing something.
>
> > If this were taken car of and if the dead keys worked consistently, then
> > the translation process would be very smooth.
>
> I think it would be a nice feature of KBabel, if it could handle conflicts
> in the header itself. But this will have to wait for some later version.

Yes, this would probably be the best solution. If there are two alternative 
versions of the headers, use the one with the later date. Of course, 
conflicts in the character encoding would be bad...

There were times when everyone was just sitting around fixing conflicts in 
the headers and not getting anything done, but as you said, we could have 
avoided this.

Cheers,
Logi

-- 
Logi Ragnarsson - logir@logi.org
Some day we all shall be out of scope

[prev in list] [next in list] [prev in thread] [next in thread]