Re: POT file for cpplib

Re: POT file for cpplib

[Karl Eichwalder]

Karl Eichwalder <ke@suse.de> writes:

> I'd like to install it as 3.4.90 - is this okay with you?  May I assume
> the next version you are going to release (semi-)officially will be >
> 3.4.90?

[...]

> Okay, thanks for the inof.  I'm going to initialize them later the
> day.

I decided to install it as 3.5.0-b20040609; thus it matches the gcc
style.  here is the initial registry record:

  <domain>cpplib
   <mailto>gcc-patches@gcc.gnu.org
   <keep>3.5.0-b20040609
   <disclaim><autosend compress>
   <remark>Install dated version with the regular version prefix; e.g.:
    20021230 as 3.3-b20021230
   <remark>used to be part of gcc

I didn't bother to send the merged .po file to the gcc mailing list.
If necessary you can fetch the cpplib page (to be initialized within the
next hours automatically):

http://www.iro.umontreal.ca/translation/HTML/domain-cpplib.html

New .po files will be sent to you as attachments.

-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)

Re: POT file for cpplib

[Joseph S. Myers]

On Wed, 9 Jun 2004, Karl Eichwalder wrote:

> I decided to install it as 3.5.0-b20040609; thus it matches the gcc
> style.  here is the initial registry record:

Whose responsibility is it to merge new translations of cpplib messages in
gcc-3.4.x.pot (as translators will continue working on 3.4 branch gcc.pot
for many months until 3.5 branches) into the cpplib domain?  I.e., will
the gcc.pot translations be used to initialize those for cpplib.pot when
3.5 branches, or will translators be expected to merge changes to cpplib
translations from gcc.pot into cpplib.pot themselves (and be told so)?

When a new version is to be submitted to the TP (when 3.5 branches), does
sending once the URL of a snapshot containing both gcc.pot and cpplib.pot
suffice, or do the instructions at <http://gcc.gnu.org/translation.html>
need changing to indicate that the same URL should be sent twice with two
different subjects?

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: POT file for cpplib

[Karl Eichwalder]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

> Whose responsibility is it to merge new translations of cpplib messages in
> gcc-3.4.x.pot (as translators will continue working on 3.4 branch gcc.pot
> for many months until 3.5 branches) into the cpplib domain?

If cpplib is also required for 3.4 I will create a separate record for
it (cpplib_3_4).  ATM, it would matter if I would initialize it from the
existing gcc or cpplib files, I guess. 

> When a new version is to be submitted to the TP (when 3.5 branches), does
> sending once the URL of a snapshot containing both gcc.pot and cpplib.pot
> suffice,

One message for both is enough; I have already a small shell script to
prepare the gcc archive file for processing; the archive traditionally
comes with two .pot files and this matter of fact "confuses" our
standard python script (fetch-pot).

> or do the instructions at <http://gcc.gnu.org/translation.html>
> need changing to indicate that the same URL should be sent twice with two
> different subjects?

This file needs an overhaul for other reasons, IIRC.

-- 
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: POT file for cpplib

[Joseph S. Myers]

On Thu, 10 Jun 2004, Karl Eichwalder wrote:

> "Joseph S. Myers" <jsm@polyomino.org.uk> writes:
> 
> > Whose responsibility is it to merge new translations of cpplib messages in
> > gcc-3.4.x.pot (as translators will continue working on 3.4 branch gcc.pot
> > for many months until 3.5 branches) into the cpplib domain?
> 
> If cpplib is also required for 3.4 I will create a separate record for
> it (cpplib_3_4).  ATM, it would matter if I would initialize it from the
> existing gcc or cpplib files, I guess. 

The cpplib messages will continue to be in gcc.pot on the 3.4 branch, with
no separate cpplib domain.  The concern is that the future work of
translators on those messages in gcc.pot gets transferred to their
cpplib.pot translations when 3.5 branches (quite likely not for six months
or more yet).

> > or do the instructions at <http://gcc.gnu.org/translation.html>
> > need changing to indicate that the same URL should be sent twice with two
> > different subjects?
> 
> This file needs an overhaul for other reasons, IIRC.

If there is anything wrong with it other than the statement that
submission of .pot files for releases is automatic, please let us know
what is wrong.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: POT file for cpplib

["Martin v. Löwis"]

Joseph S. Myers wrote:
> The cpplib messages will continue to be in gcc.pot on the 3.4 branch, with
> no separate cpplib domain.  The concern is that the future work of
> translators on those messages in gcc.pot gets transferred to their
> cpplib.pot translations when 3.5 branches (quite likely not for six months
> or more yet).

Please have a look at

http://www.iro.umontreal.ca/translation/HTML/domain-cpplib.html

I just added a comment saying that translators should use the gcc
catalog as a starting point. It also seems that Karl already arranged
to initialize the cpplib domain with translations with the gcc
translations. Does that resolve your concerns?

Regards,
Martin

Re: POT file for cpplib

[Joseph S. Myers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1242 bytes --]

On Fri, 11 Jun 2004, [ISO-8859-1] "Martin v. Löwis" wrote:

> I just added a comment saying that translators should use the gcc
> catalog as a starting point. It also seems that Karl already arranged
> to initialize the cpplib domain with translations with the gcc
> translations. Does that resolve your concerns?

My concern is what happens say six months from now when 3.5 branches.  
Until then, translators working on gcc-3.4.x.pot will have been
translating cpplib messages in gcc.pot.  What's necessary to avoid
regressions is that all the work on these translations in gcc-3.4.x
between now and when 3.5 branches gets carried forward to the cpplib
translations.  If translators start *now* with using the gcc catalog as a
starting point, then over the next several months some messages will be
translated for gcc but not cpplib, and some vice versa, and some will get
different translations that should be merged, and there will be a mess.  
The proper instruction would be to concentrate on gcc.pot exclusively and
not do any translation work on cpplib.pot until 3.5 has branched, and at
that point start working using the then current gcc.pot translations as a
base.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: POT file for cpplib

["Martin v. Löwis"]

Joseph S. Myers wrote:
> My concern is what happens say six months from now when 3.5 branches.  
> Until then, translators working on gcc-3.4.x.pot will have been
> translating cpplib messages in gcc.pot.  What's necessary to avoid
> regressions is that all the work on these translations in gcc-3.4.x
> between now and when 3.5 branches gets carried forward to the cpplib
> translations.  If translators start *now* with using the gcc catalog as a
> starting point, then over the next several months some messages will be
> translated for gcc but not cpplib, and some vice versa, and some will get
> different translations that should be merged, and there will be a mess.  
> The proper instruction would be to concentrate on gcc.pot exclusively and
> not do any translation work on cpplib.pot until 3.5 has branched, and at
> that point start working using the then current gcc.pot translations as a
> base.

So you would like to withdraw the cpplib domain? If so, please say so.

I don't share your concerns. I'm not sure what regressions you are
talking about. If you think there might be translation which actually
break gcc/cpplip operations, we should find an algorithm that rejects
translations that potentially break gcc. If you are thinking about
mere typos - well, please do have some trust in translators getting
it right.

Regards,
Martin

Re: POT file for cpplib

[Joseph S. Myers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1330 bytes --]

On Sat, 12 Jun 2004, [ISO-8859-1] "Martin v. Löwis" wrote:

> I don't share your concerns. I'm not sure what regressions you are
> talking about. If you think there might be translation which actually

Messages that are translated in 3.4.2 (say) but not in 3.5, because:

0. (Already done.)  cpplib translations initialized with current gcc-3.4.0 
translations.

1. Translator works on gcc-3.4.1.pot, translates message, translation gets 
into gcc-3.4.2.

2. 3.5 branches, gcc-3.4.2 translations auto-merged with
gcc-3.5.0-b20050101.pot, cpplib messages no longer translated in the
gcc.po files for this version.

3. Translator, working on other things, doesn't update the gcc-3.5
translations, or the cpplib translations, so even though the text of the
message hasn't changed the translation disappears in 3.5 because it is now
in a different domain.


Having the domain set up now saves needing an 18th item on the branching
checklist to be followed when 3.5 branches, but I think there should be a
comment on the domain saying that translators shouldn't yet work on that
domain; and when 3.5 branches (when the first gcc-3.5.0-byyyymmdd.pot is
submitted), that comment should be removed and the .po files then
initialized from the latest gcc.po files.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: POT file for cpplib

["Martin v. Löwis"]

Joseph S. Myers wrote:
> 3. Translator, working on other things, doesn't update the gcc-3.5
> translations, or the cpplib translations, so even though the text of the
> message hasn't changed the translation disappears in 3.5 because it is now
> in a different domain.

So what? Please consider the roles of the people involved here: the
maintainers of the software, the maintainers of translations, and the
users. It is the job of the maintainers of the software to correct bugs,
and release the software. It is the job of the translator to update
translations. If the translator doesn't make her job, the messages
don't get translated. Users of package will notice, and might
a) ignore that fact, and try to understand the English message, or
b) contact the translator, asking for an update to the translation, or
c) volunteer to take over the translation, becoming the translator

Eventually, all messages that people care about are translated to
all languages that people care about. There are transient issues all
the time, in the only way that they get corrected is by people doing
their jobs. If messages change, or appear in different places, it is
the translator's job to deal with that. Please let them make their
jobs.

> Having the domain set up now saves needing an 18th item on the branching
> checklist to be followed when 3.5 branches, but I think there should be a
> comment on the domain saying that translators shouldn't yet work on that
> domain; and when 3.5 branches (when the first gcc-3.5.0-byyyymmdd.pot is
> submitted), that comment should be removed and the .po files then
> initialized from the latest gcc.po files.

Would you like to submit an updated POT file that features such a
comment? It might be that translators don't read the comments on the
Web pages, and translate the catalog, anyway.

If you *really* don't want anybody do work on the catalog at this
moment, you need to withdraw the catalog.

Regards,
Martin