This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

glibc translations


> I'd like to update the .pot on the Translation Project site:
> http://www.iro.umontreal.ca/translation/ resp.
> http://www.iro.umontreal.ca/translation/HTML/domain-libc.html
> 
> Because you will maintain 2.3.x series, we will have to split the "libc"
> textdomain at the Translation Project as well.  If you do not mind, I
> will install a new "libc_2_3" textdomain for the 2.3 series, and keep
> the "libc" textdomain for 2.4 and later.

Thanks for bringing this up.  I have been meaning for a long time to get
libc's translations straightened out.  Heretofore we have not been very
consistent about keeping libc.pot updated and importing new translations.
I would like to figure out now the right ways to deal with this smoothly
and as automatically as possible in the future.

We indeed currently have two active branches being maintained.  We may well
have more than two active release branches in the future.  Once a branch is
in release, it will tend not to have too many changes to libc.pot, and the
older branches fewer still, but there may be some.  We will want to import
all available improved translations and new language translations into new
releases on each old branch for as long as we are maintaining it.  I
haven't actually examined the two versions to see how much they overlap,
but I suspect that the number of messages they don't share is fairly small.
If it's easier for the translation project to use just one libc.pot that is
the union of the branches, I don't think it would be a real problem to
include the extra unused messages in the .po files (so the .po are
identical across all branches).  (I have the impression that the
translators' tools for dealing with .po(t) files automate for that sort of
thing enough that you can deliver separate per-branch translations without
too much duplicated effort.  But I thought I'd suggest the possibility in
case it is easier on your end.)

The 2.3 libc.pot is out of date (a small number of new messages), and may
have a few more changes with fixes I merge in before the 2.3.7 release.
The 2.4 libc.pot is up to date in the 2.4 release and still current for
that branch right now, but it is still in somehwat active development and
might change before 2.4.1 as well.

In future I hope we can get you updated libc.pot files before we make libc
releases with enough time to get translations updated.  What is the best
way to automate this?  Our sources are in public cvs and in weekly snapshot
tarballs.  If I know the schedule on which the translation project will
fetch the libc.pot files, or wants me to submit them, then I will try to
automate something to make sure we commit updated files to the sources as
needed.  We do not usually have "pre-release" distribution tarballs in the
normal fashion, since most of the testing leading up to a release is done
by binary distribution makers using the day to day cvs sources.  From the
maintainers' instructions on the translation project web site, it sounds
like I should submit the URL of a snapshot tarball whenever its libc.pot
has changed.  I gather that for translation project "DOMAIN-VERSION.pot"
purposes, each glibc branch will be a different DOMAIN (libc, libc_2_3).
The snapshots are named glibc-YYYYMMDD or glibc-BRANCH-YYYYMMDD, which
doesn't quite fit into the VERSION scheme described.  When releases are
made, they are 2.4.1 and 2.3.7 and the like, but that can't be VERSION if I
can only submit one file with a given VERSION.

Likewise, we should automate the importing of current translations.  I
gather from the maintainers' instructions that a robot emails someone, but
I don't know much about that since I've never seen those notifications.
For us, it's better not to funnel updates through any single person
directly, to avoid them getting dropped on the floor.  The easiest thing
for me is if we can download all the current translations for each branch
in a simple mechanical way.  Then we can make this step part of our
procedures, or automate it in the snapshot process.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]