> 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..... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
