[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sync for dpkg



On Tue, Mar 08, 2005 at 01:16:37PM +0000, Scott James Remnant wrote:
> On Tue, 2005-03-08 at 18:36 +0700, Arief S Fitrianto wrote:
> 
> > On Sel, 8 Maret 2005, 5:49, Denis Barbier berkata:
> > > On Sat, Mar 05, 2005 at 08:04:07PM +0100, Christian Perrier wrote:
> > > * Strings for all programs are concatenated in the same PO file.
> > > Translators usually prefer translating most used programs (like
> > > dpkg) first.  You certainly already addressed this issue in your development
> > > branch.
> > I agreed.
> > I suggest that the strings are organized as the binary package does from the
> > same source, i.e., the PO file exist for dpkg,dselect,etc.
> > 
> Don't suppose anyone knows how to achieve this with gettext?  Last time
> I looked you listed source files in po/POTFILES.in and it turned those
> into a single .pot.
> 
> Would it mean having multiple po/ directories?

My initial remark with respect to this huge PO file was mainly to have
dselect msgids in a separate file; dselect is nowadays not a primary
target for translators because users are encouraged to try other
frontends.  For instance, it would be really nice if
  http://people.debian.org/~seppy/d-i/level4/
could display statistics for programs which should be focused on by
translators, and not for all programs shipped in the same source package.

The suggestion by Arief S Fitrianto makes a lot of sense.  I had in mind
the gettext package, but did not realize that having a po directory per
binary package may be a great idea for other packages[1].  Upstream
divided it into gettext-runtime and gettext-tools, the latter being only
used when working with PO files.  IIRC the Debian maintainer did
implement this split before upstream, which is why the gettext-base and
gettext packages have slightly different names.  But upstream also
splitted PO files, and there are now two po directories so that each
Debian package has its own catalogs.  This is very convenient because
translators can first focus on gettext-runtime which is much more
important.

You will answer that dpkg and dselect share some source code under the
lib directory, and thus PO files cannot be splitted.  Translators
can use a PO file as a compendium for the other, so duplicates are not
very harmful.  But maybe there is a simpler way.  I did not deeply dig
into this directory, but it seems to me that almost all messages are
either internal errors (displayed via ohshit*) or debugging messages (as
in checksubprocerr).  These messages are very hard to translate and do
not provide any benefit to end users; I prefer them to be not
translatable, but I know that there are other opinions.
If you have no strong objections, I can have a closer look and see if
all messages from the lib directory can be dropped.

Christian made also an interesting point; messages are extracted from
files in the same order as they are listed in po/POTFILES.in.  If you
list src/*.c first (maybe with a specific order), most visible strings
should then appear near the top of the file.

Denis
[1] Such a split only makes sense if a binary package is of higher
    priority than others.



Reply to: