Re: Sync for dpkg
> 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
Yes, and anyway if some translators lack the skills for doing so, I'll
be able to do it for them in my archive anyway : using dpkg's PO file
as a compendium for dselect PO so that common strings of the former
go into the latter.
> 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.
I think this is more or less what Scott was expecting : having someone
with a good knowledge of gettext doing this for him..:-). And you're
one of the best suited candidates for that, my dear Denis..:-)
You're probably better working on the 1.13 branch of dpkg. The best
would be using arch just like Scott, I and other dpkg contributors
do. This needs some learning as arch is really different from
centralized revision control systems. Scott has put on www.dpkg.org a
nice tutorial for using arch for dpkg development...which turns out to
be a nice arch tutorial.
Moreover, the 1.13 branch is now very clean for builds after a huge
work by Scott, again....so I suspect that working on it is a real
pleasure..:)
Scott has been able to teach me enough for being able to work with him,
so I don't doubt you can make it. This needs about 1-2 hours initial
investment on your side to install arch (either the "tla" Debian
package...or Ubuntu's "bazaar" which, I've been told, has a few
advantages).
Then you could work on your own branch quietly....
>
> 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.
Yep, I think this would be better. I can handle that in my branch.....
Reply to: