Re: [RFC] Internationalization release goals for Lenny
Nicolas François <[EMAIL PROTECTED]> (17/06/2007): > We should prepare for the RM a set of I18N release goals for Lenny. > > Grisu already sent a mail regarding translation of description to the > debian-release mailing list, but there are probably other goals. > > Here are some ideas: > * DDTP >+ Support for translated description in the package managers. > (Are there package tools which are missing this support now?) >+ Translation material available on the mirrors > (IIRC, this is available on most mirrors for sid, but not for lenny) > * Get rid of non po-debconf templates. > * New channel for distribution of translated material (tdeb, language >packs or others) > * allow support for more languages in DI >(memory/space issues, support for regional CDs, etc.) * UTF-8 manpages -- Thomas Huriaux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Internationalization release goals for Lenny
Christian Perrier <[EMAIL PROTECTED]> (17/06/2007): > > * UTF-8 manpages > > Some ppl talked to me about this here. I suppose that using po4a for > man pages l10n will help, right ? Hmm, I don't see how. Changing the po4a encoding option is as easy as a script converting all manpages. -- Thomas Huriaux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Review in progress for solr debconf templates
Christian Perrier <[EMAIL PROTECTED]> (16/09/2007): > > If there is indeed a status page showing which debconf templates are > > currently being reviewed by debian-english, how about placing a link to it > > near the top of each debconf language team page, with text (e.g.) > > > > "Before translating a debconf template, please check it is not currently > > [link]under review[/link] by the Debian English team. This review process > > is likely to change the original strings, so please wait until it has > > concluded, then update your translation." > > > That makes sense. Only small problem: I have to find who can do > this..:-) > > That would probably be Thomas Huriaux or Nicolas François who are the > people who know how scripts that generate these pages work. I've committed the explanation about the review process, it should be online in a few hours. Cheers, -- Thomas Huriaux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of Debconf templates l10n not updating
Hi, Esko Arajärvi <[EMAIL PROTECTED]> (16/03/2008): > For some reason the translation status of debconf templates at > http://www.debian.org/intl/l10n/po-debconf/rank is not updating. Apparently > the script runs, because is says: "This page was generated with data > collected on: March 15th, 2008.", but packages with recently closed > translation bugs (such as resolvconf or update-inetd) are not shown as > translated. All the languages I checked seem to be affected. The mirror on i18n.debian.net is no longer updated. Can somebody with proper access rights (Nicolas ? Felipe ?) fix the problem? -- Thomas Huriaux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HTML strict patch for gen-files.pl commited
Christian Perrier <[EMAIL PROTECTED]> (03/11/2005):
> > in l10n/po/pa.fr.html there are addintional errors, which are from
> > the page content.
> >
> > Line 138, character 314: "771751936" is not a character number in the
> > document character set
> > Line 138, character 326: "1560281088" is not a character number in the
> > document character set
> > Line 138, character 339: "536870912" is not a character number in the
> > document character set
> >
> > Can one from i18n please look into that? Please look at the row for
> > usermode in http://www.debian.org/international/l10n/po/pa
>
> There's probably nothing we can do here. The translator's name comes
> from the PO file and Amanpreet did put his name using the Gurmukhi
> script in the Last-Translator field, which is certainly right.
>
> It seems that some of the characters he used are not interpreted
> correctly
>
> Denis, as the author of the scripts which generate this page, can you
> have a look?
Denis, I have commited the attached patch to the dl10n cvs. It fixes the
problem (thanks a lot to Julien Cristau who found the solution). I think
you have to force a new check of the usermode package to fix the
database.
--
Thomas Huriaux
Index: dl10n-check
===
RCS file: /cvsroot/debian-l10n/dl10n/dl10n-check,v
retrieving revision 1.19
diff -u -r1.19 dl10n-check
--- dl10n-check 22 Sep 2005 08:56:43 - 1.19
+++ dl10n-check 3 Nov 2005 14:21:33 -
@@ -651,7 +651,7 @@
return $qstring if $@;
my $result = $converter->convert($string) or return $qstring;
my $ret = "";
-while($result =~ m/(.)(.)(.)(.)/g) {
+while($result =~ m/(.)(.)(.)(.)/sg) {
my $ucs = ord($1)*0x100 + ord($2)*0x1 + ord($3)*0x100
+ ord($4);
$ret .= ($ucs > 0x7e ? "&#$ucs;" : chr($ucs));
}
signature.asc
Description: Digital signature
Re: Parsing ../10n/material/data/ files
Christian Perrier <[EMAIL PROTECTED]> (07/11/2005): > > > The trouble I think is that the portuguese mailing list already has use > > for those control messages but for the brazilian translators (and not > > the portuguese). So using it would at the same time would result in > > confusion on both parts. > > > Hmmm, pseudo-urls include the name of the PO file so I guess it's > technically possible that one list currently be used for two > languages... > > However, this should be checked in the dl10n scripts code. The filename is not used in the current version of dl10n-txt, so it won't work. Here is an example of the kind of results, I have manually added the line: po!fr_FR.po!2005-10-31 08:23:40 +!rfr!Aurelien Ricard!2005-11-00113 Package: adduser STATUS: po!fr.po!2005-10-31 08:23:40 +!itt!Aurelien Ricard!2005-11-00113 po!fr_FR.po!2005-10-31 08:23:40 +!rfr!Aurelien Ricard!2005-11-00113 output of dl10n-txt (same result for fr and fr_FR): |adduser |91.9 | 182/8/8 |po(itt, 7 days rfr,7 days) I haven't check yet if there is an easy solution. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Some names are missing from the list of translators
Daniel Nylander <[EMAIL PROTECTED]> (13/11/2005): > I wonder why some names doesn't show up in the list even though > they are in the translation? > > Take a look at: > http://www.debian.org/international/l10n/po-debconf/sv > > Some of the files (such as pileup, atftp etc..) include my name > but the name doesn't show up in the list. These files are of dos type, so the line "Last-Translator: Daniel Nylander <[EMAIL PROTECTED]>\n"\r does not match the regexp ^"Last-Translator:\s*(.*)\\n"$ (\r\n instead of \n at the end of each line) Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Some names are missing from the list of translators
Luk Claes <[EMAIL PROTECTED]> (13/11/2005):
> Daniel Nylander wrote:
> > Thomas Huriaux skrev:
> >
> >
> >>>but the name doesn't show up in the list.
> >>>
> >>>
> >>
> >>Some of the files (such as pileup, atftp etc..) include my name
> >>
> >>
> >>These files are of dos type, so the line
> >> "Last-Translator: Daniel Nylander <[EMAIL PROTECTED]>\n"\r
> >>does not match the regexp
> >> ^"Last-Translator:\s*(.*)\\n"$
> >>(\r\n instead of \n at the end of each line)
> >>
> >>
> >
> >
> > Hmm, weird. I used the same editor as I did for many others
> > (gtranslator, poedit, kbabel).
> > Is there any chance you might change the regexp to include even these
> > types of formated files?
> > (or shall I bugreport all translations again and wait a few weeks? :-))
>
> I added a .* after \\n, so no need to bug all translators who use EOLs
> that don't end with \n :-)
I've fixed it as following (in the dl10n cvs):
-if (m/^"Last-Translator:\s*(.*)\\n"$/m) {
+if (m/^"Last-Translator:\s*(.*)\\n"\r?$/m) {
Luk, I don't know where you have fixed it, but the .* should be added
after the " and not before. I also prefer to limit it to \r? and not .*.
To have it updated on the webpage, you will have to wait either for
a new upload of each package or for Denis Barbier to force a new check
of these packages.
--
Thomas Huriaux
signature.asc
Description: Digital signature
Re: Some names are missing from the list of translators
Luk Claes <[EMAIL PROTECTED]> (13/11/2005):
> Thomas Huriaux wrote:
> > Luk Claes <[EMAIL PROTECTED]> (13/11/2005):
> >
> >>Daniel Nylander wrote:
> >>
> >>>Thomas Huriaux skrev:
> >>>
> >>>
> >>>
> >>>>>but the name doesn't show up in the list.
> >>>>>
> >>>>>
> >>>>
> >>>>Some of the files (such as pileup, atftp etc..) include my name
> >>>>
> >>>>
> >>>>These files are of dos type, so the line
> >>>>"Last-Translator: Daniel Nylander <[EMAIL PROTECTED]>\n"\r
> >>>>does not match the regexp
> >>>>^"Last-Translator:\s*(.*)\\n"$
> >>>>(\r\n instead of \n at the end of each line)
> >>>>
> >>>>
> >>>
> >>>
> >>>Hmm, weird. I used the same editor as I did for many others
> >>>(gtranslator, poedit, kbabel).
> >>>Is there any chance you might change the regexp to include even these
> >>>types of formated files?
> >>>(or shall I bugreport all translations again and wait a few weeks? :-))
> >>
> >>I added a .* after \\n, so no need to bug all translators who use EOLs
> >>that don't end with \n :-)
> >
> >
> > I've fixed it as following (in the dl10n cvs):
> > -if (m/^"Last-Translator:\s*(.*)\\n"$/m) {
> > +if (m/^"Last-Translator:\s*(.*)\\n"\r?$/m) {
> >
> > Luk, I don't know where you have fixed it, but the .* should be added
> > after the " and not before. I also prefer to limit it to \r? and not .*.
>
> I don't see any reason to put it behind the ",
"Last-Translator: ^"Last-Translator:
(spaces)\s*
Daniel Nylander <[EMAIL PROTECTED]> (.*)
\n \\n
" "
\r \r?
(end of the line) $
> nor do I understand why
> you want to limit it to "\r?", maybe we should change it so that all
> common EOLs are supported: \n, \r and \n\r?
\n (unix EOL) is ok
\r\n (dos EOL) is ok with \r?
\r (mac EOL) gives disastrous results with everything (debconf-updatepo,
...), so if somebody send such a file, I hope the maintainer won't
include it. That's why I think it's better to limit it to \r?.
> If you want to limit it to \r, did you check if your expression works as
> I'm not sure if it there shouldn't be an extra "\" ...
no, \\ means \
Cheers,
--
Thomas Huriaux
signature.asc
Description: Digital signature
Re: Work on a centralized infrastructure for i18n/l10n
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> (21/12/2005): > - a way to work with things that are not po files: > * wml files > * some documents (XML or SGML) > * manpages > > [...] > > [ Note: I know we have po4a but sometimes upstream won't introduce the use of > po regardless of how we ask for it ] IMO, that's not the best approach. If the upstream maintainer does not want to use po4a, we should find a way to use po4a in parallel, i.e. having the translators working only on po files and sending the regenerated documents upstream. We should definitely try to drop these unfriendly formats for translators. The goal is therefore more to create the infrastructure to handle this situation than to try to keep these formats and work with them. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Work on a centralized infrastructure for i18n/l10n
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> (21/12/2005): > On Wed, Dec 21, 2005 at 12:28:15PM +0100, Thomas Huriaux wrote: > > > > IMO, that's not the best approach. If the upstream maintainer does not > > want to use po4a, we should find a way to use po4a in parallel, i.e. > > having the translators working only on po files and sending the > > regenerated documents upstream. We should definitely try to drop these > > unfriendly formats for translators. > > I don't like to use po for documentation. Translators lose context and that > sometimes mean worst translators. That being said, I'm probably not alone and > that means that, even if po4a is available, it should not be forced down > every translator's throat. I confirm that you are not alone. But I don't understand this context problem. When I translate a program, I check where the strings in the po appear in the program. If I translate a po-debconf, I use some tools such as podebconf-display-po to understand when and how the strings I have translated appear. This is because I can't (I think like everybody) figure out what a single string really means out of its context. The same thing applies for the documentation: if I translate a manpage or an sgml document, I will have to convert it into a "human" format, and check if my "foobar1bar2" is what I understood when I was translating this file. The context problem may be a little bit worse with po files than with initial files, but you still have to go through the proofreading step. And you already have this problem with the current po files, i.e. program translation and po-debconf for example. > > The goal is therefore more to create the infrastructure to handle this > > situation than to try to keep these formats and work with them. > > We have some formats that will never be converted to po4a (like wml) "formats that will never be converted" or "formats that we will never be able to convert"? There is an under-development module for wml. > so we should consider those (and more to come). Being flexible (and > not forcing everybody to use your pet tool) is a better way to have > translator teams integrate into a common tool. If you don't do it that > way you'll end up having some i18n tools use different tools because > they are not comfortable with the ones being forced upon them. I don't force anybody to use "my pet tool", I just think that the po format (using xgettext, xml2pot, po4a or whatever) is the best interface for translators. After this, you are free to use the tools you want. I think that having the common following interface for every format is the best way to be flexible: conversion tool translation tool original file <--> po file <> translator With this, package maintainers are free to use the format/tools they want (xml with xml2pot, sgml with po4a, ...); translation teams are free to use the translation tools they want (text editors, pootle, mail interfaces, ...). Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Work on a centralized infrastructure for i18n/l10n
Christian Perrier <[EMAIL PROTECTED]> (21/12/2005): > > > I don't force anybody to use "my pet tool", I just think that the po > > format (using xgettext, xml2pot, po4a or whatever) is the best interface > > for translators. After this, you are free to use the tools you want. I > > think that having the common following interface for every format is > > the best way to be flexible: > > > > conversion tool translation tool > > original file <--> po file <> translator > > > > > > With this, package maintainers are free to use the format/tools they > > want (xml with xml2pot, sgml with po4a, ...); translation teams are free > > to use the translation tools they want (text editors, pootle, mail > > interfaces, ...). > > > Yep. What you describe is a situation where PO is the central common > format that's used on the central infrastructure. This means that all > automation/updateness checking tools that exist for handling PO files > can be used on the central system to manage the data presented to > users (users here==translators). > > This does not prevent us to propose translators to get the translation > material in whichever format they would like to usethis is what I > understand from your above scheme. Do you mean something like this? translation tool conv tl|<--->| original file <-> po file| |translator |<-> other format <-->| conv tl transl tool It could indeed be a good idea for po-reluctant people. Everybody would be free to choose either to translate directly po files, or to reconvert po files into another format and then translate it. It's just a little bit more complex, but it should be doable. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Removal of http://www.debian.org/intl/l10n/templates/
"Felipe Augusto van de Wiel (faw)" <[EMAIL PROTECTED]> (13/03/2006): > On 03/11/2006 05:12 AM, Christian Perrier wrote: > > Quoting SZERVÁC Attila ([EMAIL PROTECTED]): > >> On Fri, 10 Mar 2006, Denis Barbier wrote: > > Denis is talking about the status pages for debconf templates that do > > not use po-debconf. These templates had to be translated "the hard > > way" by putting translations directly in the templates file, without > > using PO files. > > > > The switch to po-based debconf translations ahppened shortly after the > > release of woody, in September 2002. After active campaining by > > translators, there is no more significant packages that still use the > > old system. The very few that still do are unmaintained and crappy > > stuff none cares about. > > > > This is why Denis proposes to abandon the above pages. > > Should we report RC-bugs to these packages? Or create a list > (maybe a wiki pages) with packages that still uses old format? Maybe > some packages could be removed. Most of these packages already have a bug, minor or wishlist. Each time a new package appears not to be using po-debconf, I fill a bug immediatly (the last one is gom, #356202). I'm not sure increasing the severity of these bugs is the right solution -- not having debconf translatable is not critical. Reporting every maintainer to [EMAIL PROTECTED] may be a better solution. -- Thomas Huriaux signature.asc Description: Digital signature
Re: Reporting bugs against packages not using po-debconf
"Felipe Augusto van de Wiel (faw)" <[EMAIL PROTECTED]> (13/03/2006): > On 03/13/2006 03:49 PM, Thomas Huriaux wrote: > > "Felipe Augusto van de Wiel (faw)" <[EMAIL PROTECTED]> (13/03/2006): > >> On 03/11/2006 05:12 AM, Christian Perrier wrote: > [...] > >>>The switch to po-based debconf translations ahppened shortly after the > >>>release of woody, in September 2002. After active campaining by > >>>translators, there is no more significant packages that still use the > >>>old system. The very few that still do are unmaintained and crappy > >>>stuff none cares about. > >>> > >>>This is why Denis proposes to abandon the above pages. > >> > >>Should we report RC-bugs to these packages? Or create a list > >>(maybe a wiki pages) with packages that still uses old format? Maybe > >>some packages could be removed. > > > > Most of these packages already have a bug, minor or wishlist. Each time a > > new package appears not to be using po-debconf, I fill a bug immediatly > > (the last one is gom, #356202). I'm not sure increasing the severity of > > these bugs is the right solution -- not having debconf translatable is > > not critical. Reporting every maintainer to [EMAIL PROTECTED] may be a > > better solution. > > Hmmm, I was thinking about the very old ones, not the new ones. > But I did not phrase it clearly, sorry. :( > > I was thinking about list which packages could be updated to use > po-debconf and which ones are too old and unmaintained and should be > "hinted" for removal. Specially because all the work to move for po-debconf > was done quite a while ago (woody times), well, in fact it was just an > offer to help tracking the remaining packages and list them in a wiki page > or something like that. :) The list of packages with their bugs is the following: anthy 295803 asterisk-chan-misdn 330542 b2evolution 351376 bottlerocket205769 cdebootstrapwontfix, maintainer refuses to explain why cfal283633 cfalrtl 351379 chdrv 205793 cpml233100 cricket 205814 cxml233104 daemontools-installer 237457 debian-edu-config internal use debsecan351380 delo250269 diald 200124 dict-gcide 207859 diffmon 137637 discover351381 filterproxy 330547 gdm 261086 gidentd 194259 gom 356202 hybserv 351383 ispell-fi kind of internal use kerberos-configs295495 libmail-bulkmail-perl 235166 libots 233102 libroxen-imho 286066 lowmem d-i lukemftpd 296054 masqmail235493 miscfiles kind of internal use mkvmlinuz 298972 nagat 257678 ndtpd 257679 newpki-client 334229 nvidia-cg-toolkit 351388 prelude-nids351390 qmail 351394 quake2-data 235635 radioclk206835 slimserver 351374 suck286065 usb-discoverd-i waproamd250275 watchdog351398 webcalendar 351399 x-symbol198862 yadatest template zope-cmfplone internal use zope-docfindereverywhere351402 zope-zshell 232437 The number of the bug give you a hint to know how badly maintained is the package. Once again, before removal, I would mail [EMAIL PROTECTED], waiting for the package to be orphaned if the maintainer is really MIA, and ask to remove the package if nobody wants to take over package maintenance. If you want to create a wiki page or something to ease the work on this list, I'm ready to help. -- Thomas Huriaux signature.asc Description: Digital signature
Debconf translation of Apache modules
Hi, Paweł, can you please give some guidelines to i18n people to know what is the best solution for you to translate these debconf templates and how you intend to spread translations among all packages? ___ _|_po-debconf__| |__package___|__%__|details| [...] |libapache-mod-auth-useragent| |0/0/7 | |libapache-mod-cgi-debug | |0/0/7 | |libapache-mod-filter| |0/0/7 | |libapache-mod-index-rss | |0/0/7 | |libapache-mod-ldap | |0/0/7 | |libapache-mod-mp3 | |0/0/7 | |libapache-mod-random| |0/0/7 | |libapache-mod-relocate | |0/0/7 | |libapache-mod-repository| |0/0/7 | |libapache-mod-text2html | |0/0/7 | |libapache-mod-trigger | |0/0/7 | [...] ||_|___| |TOTAL (assume BTS = 1; fr) |98.6%| 8569/8/111 | ||_|___| Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Preview of the i18n and l10n paper for Debcon6
oth.debian.org/projects/debian-l10n/ === Section 3.2 === I'm afraid that to complete this section will make section 2.1 obsolete === Section 3.4 3.4.3: if you want to be complete, you should add "/ll.po" at the end of every subject. === Section 4.1 For your po file example to be complete, you should fill the Content-type and Content-transfer-encoding, especially since it is often the most difficult to understand for new translators. === Section 4.6.1 Is a tutorial explaining how to install reportbug really needed in such a document? IMO, it is really out of topic. Otherwise, you should also explain how to compile wml, how to install po-debconf, ... which would make the document 300 pages long. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Google summer of code: i18n infrastructure
"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> (15/05/2006): > 1) integrate www.debian.org/intl/l10n/po-debconf/nl with the bot-page on > dutch.debian.net, and similar for other teams. This has been proposed > before, but AFAIK nothing has materialized, not sure if anyone is > currently working on this Do you mean something like this? $ dl10ndebconf ___ _|_po-debconf__| |__package___|__%__|details| |arno-iptables-firewall |95.1%|39/2/0 |podebconf(lcfc, 2 days) |bacula |40% |2/1/2 |podebconf(taf, 1 days) |courier |93.7%|30/0/2 |podebconf(rfr, 1 days) |logtool |81.2%|13/3/0 | |openssh |76.4%|13/4/0 |podebconf(rfr, 2 days) |tex-common |61.9%|13/5/3 |podebconf(rfr, 3 days) |w3c-markup-validator|50% |2/2/0 |podebconf(taf, 2 days) |watchdog| |0/0/4 |podebconf(rfr, 1 days) ||_|___| |TOTAL (assume BTS = 1; fr) |99.6%| 8614/17/11 | ||_|___| If yes, see the debian-l10n project on alioth. > [1] http://www.debian.org/intl/l10n/po-debconf/nl or > http://www.debian.org/intl/l10n/po/nl mostly, though the latter has > mostly non-debian-specific stuff You have an "Upstream:" field in the database used to generate these pages, based on the presence of a diff in the source package and the presence of a dash in the version. This can be easily used by dl10n-txt (see the --debian (no diff, no dash) or the --diff-only (no diff) options). However, with these criteria, wxwidgets is a debian-specific package while aptitude isn't, but these are exceptions. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Google summer of code: i18n infrastructure
"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> (15/05/2006): > On Monday 15 May 2006 16:01, Thomas Huriaux wrote: > > Do you mean something like this? > > > $ dl10ndebconf > > ___ > > _|_po-debconf__| > > [...] > > |TOTAL (assume BTS = 1; fr) |99.6%| 8614/17/11 | > > ||_|___| > > > > If yes, see the debian-l10n project on alioth. > > yep, that's exactly what I meant, but it needs to be on the debian.org/intl > pages: > > We currently have sections there > 1) Packages with po-debconf support and for which translation is underway > 2) Packages with po-debconf support and for which translation is done > 3) Packages with po-debconf support and for which translation is to do > > Should become (IMHO): > 1) Packages with po-debconf support for which the translation needs an >update: everything with partial translation that isn't being worked on. >Mark with RFU (request for update) date (automaticaly when one is send >out by podebonf-report-po?). > 2) Packages with po-debconf support and for which translation is underway: >everything that's in RFR or LCFC state > 3) Packages with po-debconf support and for which translation is done: >done in package and done in BTS (with indication of which is which) > 4) Packages with po-debconf support and for which translation is to do There has been such a page (at least for French) a long time ago, but it no longer exists: http://web.archive.org/web/20041124094735/http://graal.ens-lyon.fr/~mquinson/debian/po-debconf.fr.html To add this page to the website should not be a coding problem, IMO. We just need to unify the database formats used between different language teams (and that is a problem :-)) > > > [1] http://www.debian.org/intl/l10n/po-debconf/nl or > > > http://www.debian.org/intl/l10n/po/nl mostly, though the latter has > > > mostly non-debian-specific stuff > > > > You have an "Upstream:" field in the database used to generate these > > pages, based on the presence of a diff in the source package and the > > presence of a dash in the version. This can be easily used by dl10n-txt > > (see the --debian (no diff, no dash) or the --diff-only (no diff) > > options). > > However, with these criteria, wxwidgets is a debian-specific package > > while aptitude isn't, but these are exceptions. > > right I see 3 classes of apps here: > 1) debian stuff (apt, dpkg, ... i.e. Debian is upstream), is probably in >debian-native packages (not sure if this is generally true) > -> primary target for translation by Debian l10n teams > 2) no upstream translation team > -> secondary target for translation by Debian l10n teams, leave alone > untill debian-specific stuff is done. > 3) upstream has a translation team (KDE, Gnome, ...) > -> shouldn't be touched directly by Debian, integrate any work with > upstream translation team I agree, this is what we (the French team) are doing. > So: 1 = no diff, no dash > 2 ~= no diff (upstream team might not have gotten to specific component > yet so only aproximate) Hmm no, this one is a mistake (there is a lintian warning for this kind of upload, the only good reason I see to have no diff but a dash are brutal repackaging). One of the solution would be to have a manually generated database that contains all the may-be-translated-when-you-have-time packages. > 3 ~= diff Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: ranslation owner (was: Slides from the Debconf6 2nd BOF about i18n infrastructure)
Christian Perrier <[EMAIL PROTECTED]> (24/05/2006): > Quoting Stefano Canepa ([EMAIL PROTECTED]): > > > I don't know if there is a reference but: > > ITT = Intent To Translate (as ITP) > > RFR = Request For Review > > LCFC = Last Chance For Changes > > s/Changes/Comments > > You can add "TAF" to this, which means "Work To Do" (Traduction A > Faire in French"taf" being also french slang for "work") > > When it comes at the status of translation, we also have: > > BTS: reported in Debian BTS. Should also include the bug number for > tracking reasons > > HOLD: put on hold by a coordinator, either a team coordinator or the > maintainer. Usually because one of these feels that the strings > are not ready for translation work > > FIX: fixed in the maintainer's reporsitory but not in the published > work This one is a convenience tag for bugs fixed in NMU, very similar with done (but due to the bts structure, it can't be the same tag). When the translation has been included in the maintainer's repository, we usually use the hold tag, followed by a manual done when the package has been uploaded. > DONE: used in status mails to force the crawler which parses the list > to recognize that the work has indeed be done And this one is either a manual done when there is no bug (as you stated), or an automatic status change if the related bug has been closed. You also have the WONTFIX tag, which is easy to understand. -- Thomas Huriaux signature.asc Description: Digital signature
Re: DDTP, PO format and the future Debian i18n infrastructure
Hi, Christian Perrier <[EMAIL PROTECTED]> (04/08/2006): > So, now, the DDTP is something that gives results...good. > > However, the current translation process (the mail interface) is a bit > different than the usual way translation teams are working. For > instance, this explains why the French effort is currently mostly > stopped for the DDTP. > > What would be good now is getting an interface with the PO format so > that translators can work on PO files for DDTP translations. > > Grisu, before we get the nice infrastructure (probably based on > Pootle) which we will discuss in Extremadura, do you think that some > crude way to get PO files for the DDTP would be possible ? > > That requires writing something that will convert the Debian > descriptions and their translations to PO format. IIRC, Otavio did > write some stuff already, 1 or 3 years ago. > > Maybe a po4a module would be possible.this should be checked with > "Mr. po4a", namely Nicolas François (and his fellow co-maintainers: > Thomas Huriaux, Martin Quinson, etc). I had a look on this issue a few weeks ago, and intltool-debian seems to do already exactly what seems to be needed. To summarize: just mark the "Description:" field as translatable (i.e. prepended with an underscore), and you can use tools such as po2debconf and debconf-updatepo. The resulting PO files look like this one: http://haydn.debian.org/~thuriaux-guest/ddtp/a2ps/po/templates.pot Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: DDTP, PO format and the future Debian i18n infrastructure
Otavio Salvador <[EMAIL PROTECTED]> (04/08/2006): > Thomas Huriaux <[EMAIL PROTECTED]> writes: > > Christian Perrier <[EMAIL PROTECTED]> (04/08/2006): > >> So, now, the DDTP is something that gives results...good. > >> > >> However, the current translation process (the mail interface) is a bit > >> different than the usual way translation teams are working. For > >> instance, this explains why the French effort is currently mostly > >> stopped for the DDTP. > >> > >> What would be good now is getting an interface with the PO format so > >> that translators can work on PO files for DDTP translations. > >> > >> Grisu, before we get the nice infrastructure (probably based on > >> Pootle) which we will discuss in Extremadura, do you think that some > >> crude way to get PO files for the DDTP would be possible ? > >> > >> That requires writing something that will convert the Debian > >> descriptions and their translations to PO format. IIRC, Otavio did > >> write some stuff already, 1 or 3 years ago. > >> > >> Maybe a po4a module would be possible.this should be checked with > >> "Mr. po4a", namely Nicolas François (and his fellow co-maintainers: > >> Thomas Huriaux, Martin Quinson, etc). > > > > I had a look on this issue a few weeks ago, and intltool-debian seems > > to do already exactly what seems to be needed. > > To summarize: just mark the "Description:" field as translatable (i.e. > > prepended with an underscore), and you can use tools such as po2debconf > > and debconf-updatepo. > > The resulting PO files look like this one: > > http://haydn.debian.org/~thuriaux-guest/ddtp/a2ps/po/templates.pot > > Long time ago I wrote a utility to merge the translation files. Do a > look it. > > Using it you can reuse previous translations and then generate po > files using your hack :-D Thanks, but if I want to go on with my hack, I prefer to use debconf-gettextize :-) However, instead of having once again (such as with the bots) a different system for every language team, I'd like to know/discuss the kind of PO files that are used. IIRC, the PO files I have seen a few weeks ago are only one string per description, and the translator has to be careful on the structural part (i.e. to wrap lines manually with "\n", to add a space at the beginning of every line, to add a "." for a new paragraph, etc.), disabling all the advantages to work with the PO format. But I can't find anymore these files. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Scripts that produce unstable.gz
Hi, Marco Ferra <[EMAIL PROTECTED]> (06/08/2006): > Can any of you inform me where can I find the source code of the scripts > that produce the files/information at: > > http://merkel.debian.org/~barbier/l10n/material/data/ dl10n-check of the debian-l10n project on alioth (in the CVS): http://alioth.debian.org/projects/debian-l10n/ > http://www.debian.org/intl/l10n/po-debconf/pt_PT unstable.gz parsed by the scripts available at http://cvs.debian.org/webwml/english/international/l10n/scripts/?root=webwml > and from where do they gather the data ? from the source packages of unstable. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: ranslated packages descriptions progress
Michael Bramer <[EMAIL PROTECTED]> (10/08/2006): > On Thu, Aug 10, 2006 at 04:09:33PM +0300, Gintautas Miliauskas wrote: > > > AIUI, if you do that it will reserve a chunk of the database to you. > > > When you send a translation it checks first if it has sent it to you > > > before accepting it. You can't request a translation for a specific > > > package, nor can you request it non-exclusively. > > > > Ouch. Thing is, I am trying to get the web-based translation system > > Pootle to grok DDTP descriptions. Pootle stores translations > > as .po files internally. I already have the Translation-?? dump > > <-> .po bridge running, but it appears that this isn't very useful > > because actually a DDTS database <-> .po bridge is needed. So, > > question is, what should I do if I want to talk to the database > > directly? > > NO! > > if we have a working pootle system for the ddtp, we will shutdown the > ddtp server. > > Don't depend on this temp. system. > > For pootle we need a Packages2po and a po2Translations script for the > daily work. Please don't forget that intltool-debian scripts are already mainly doing this job. This is not a hack to use them: even if the main frontends (debconf-updatepo and po2debconf) have a name which is debconf-related, these tools are generic and can be used in this situation. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Cyrus-imapd-2.2 debconf template changed, some translations missing
Hi, Sven Mueller <[EMAIL PROTECTED]> (15/08/2006): > I would like to ask you for help with the translation of our debconf > template. Several translations already exist and only need a small > update while others are completely missing. Here are the stats from > debconf-updatepo: > > [...] > > As you see, there isn't much to translate even for those languages that > are not yet represented in our package. > > POTFILES.in and most recent version of the existing .po files are > available at: > https://mail.incase.de/svn/cyrus22/trunk/cyrus-imapd-2.2.13/debian/po/ Could you please first fix your templates? I found the following problems: * Comparation -> Comparison * The interrogative form of a boolean template should be in the short description and not in the long description. I suggest you to apply the following fixes: - _Description: Removal of the mail and news spools + _Description: Remove the mail and news spools? - Should the Cyrus mail and news spools, as well as the user's - sieve scripts, be removed when the package is purged? + The Cyrus mail and news spools, as well as the user's sieve scripts + can be removed when the package is purged. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Catching packages with long-standing l10n bugs
Hi, During the Extremadura meeting, we decided to launch an NMU campaign for l10n bugs. The first step of such a campaign is to detect which packages have long-standing l10n bugs. I've written a "dl10n-nmu" script, available in the debian-l10n project CVS on alioth [1], which scores packages according to the number and the age of l10n bugs. The results (daily updated) are available at http://haydn.debian.org/~thuriaux-guest/l10n-nmu/nmu_bypackage.html http://haydn.debian.org/~thuriaux-guest/l10n-nmu/nmu_maintainer.html This script detects all l10n bugs filled against a package, tries to detect those concerning po-debconf (which is our main target for NMU), and scores them according to the following rule: score = sum ( age_of_the_bug ) For example, if the package foo has the following bugs: 1 [INTL:nl] Dutch debconf templates translation filled 8 weeks ago 2 [INTL:pt_BR] debconf translation update filled 15 weeks ago 3 Problem with the display in an UTF-8 environment filled 32 weeks ago 1 will score 8, 2 will score 15 and 3 will score 0 as it is not a po-debconf related bug. The total score will therefore be 23. There are many false-positives and false-negatives, as this ranking is based on the subject field, which is actually not very standardized. It could be good if every translation team coordinator retitles the bugs according to a common template. We use for French: : [INTL:fr] French debconf templates translation if there is no debian/po/fr.po file in the package, and : [INTL:fr] French debconf templates translation update otherwise. For program translation, replace "debconf templates" by "program", and for manpages, by "manpages". As you can see on the pages, there are packages "not using debconf" and packages "not in unstable". Unless someone volunteers to clear these bugs, I will take care of them. Note also that it is only a ranking, packages with a low score shouldn't be dealt with. Suggestions, comments and patches are obviously welcomed. [1] http://alioth.debian.org/projects/debian-l10n -- Thomas Huriaux signature.asc Description: Digital signature
Re: Catching packages with long-standing l10n bugs
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> (15/09/2006): > On Thu, Sep 14, 2006 at 08:19:20PM +0200, Thomas Huriaux wrote: > > During the Extremadura meeting, we decided to launch an NMU campaign for > > l10n bugs. The first step of such a campaign is to detect which packages > > have long-standing l10n bugs. I've written a "dl10n-nmu" script, available > > in the debian-l10n project CVS on alioth [1], which scores packages > > according to the number and the age of l10n bugs. > > > > The results (daily updated) are available at > > http://haydn.debian.org/~thuriaux-guest/l10n-nmu/nmu_bypackage.html > > http://haydn.debian.org/~thuriaux-guest/l10n-nmu/nmu_maintainer.html > > Looks really cool. > > > Suggestions, comments and patches are obviously welcomed. > > IMHO localeconf, due to it's approach (setting up user's l10n) should be > handled before any other package. Note that localeconf has been requested to be removed from the archive (#379033). > Does the rating also take into account popcon? I think there will less > users installing fujiplay than say, hotplug. It is now introduced through the basic coefficient: 2 - (popcon_rank / 1) using the "source", "inst" ranking, e.g. hotplug's score will be multiplied by around 1.9, while fujiplay's score will be multiplied by around 1.03 (but it's no longer on the page as I closed the bugs a few hours ago). Thanks for your comments. -- Thomas Huriaux signature.asc Description: Digital signature
Re: (forw) Re: Launching a NMU campaign for pending l10n bugs
Hi, Clytie Siddall <[EMAIL PROTECTED]> (16/09/2006): > > On 16/09/2006, at 7:47 PM, Christian Perrier wrote (in part): > > >If a DD wants to NMU a package, he should pick one at the top of the > >ranking, then check _every_ bug filled against the package and sort > >out > >those which are po-debconf related and those which are not. > > Christian, can we translators help with identifying the po-debconf > bug reports, by including "po-debconf" in the email subject line? > > I currently just use "INTL:VI" for my subject, as I'm not sure what > else to put. We should indeed standardize the subject line. If you have a look at the script creating the pages, I've indeed a special check for you assuming that all bugs entitled "INTL:vi" are po-debconf-related :-) > Could we, for example, use (where XX is the language code): > > INTL:XX D-I > INTL:XX debconf > INTL:XX package_name > > for translation submissions for the installer, debconf files and > program files? > > And is it useful to mark which are first-time translations and which > are updates? With the French translation team, we are using the following pattern: : [INTL:fr] French debconf templates translation : [INTL:fr] French debconf templates translation update : [INTL:fr] French program translation : [INTL:fr] French program translation update If you have a sorted list (at least differenciating po-debconf and program bugs, to check if it's an update being easy), we could retitled your bugs according to this pattern (or another one if somebody disagrees with the one we use). Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Work started on Release Notes for Etch
Yuri Kozlov <[EMAIL PROTECTED]> (17/09/2006): > 2006/9/17, Frans Pop <[EMAIL PROTECTED]>: > >See [1] for general information on how to get a checkout from the DDP CVS. > http://cvs.debian.org/ddp/manuals.sgml/release-notes/?root=debian-doc&only_with_tag=etch > > > Hey, where are .po files ? :) > po4a is not ready for release-notes sgml ? It should be ready (at least with the version in Etch), however the Makefile should be modified to include PO files in the build system. DDP maintainers, do you think it is appropriate to support po4a within the build system for translators who want to use it, or should we only commit the re-generated documents? If it's ok, I will work on a patch. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: (forw) Re: Launching a NMU campaign for pending l10n bugs
Christian Perrier <[EMAIL PROTECTED]> (16/09/2006): > Christian Perrier <[EMAIL PROTECTED]> (15/09/2006): > > Quoting Lucas Wall ([EMAIL PROTECTED]): > > > On 15/09/06 02:00, Christian Perrier wrote: > > > > I presented the procedure we used back in early 2005 and everybody > > > > agreed that we can re-use most parts of the process and > > > > infrastructure. > > > > > > > > Do you think that we could wake up things and re-use that > > > > infrastructure? If you can't, we will of course setup something > > > > else, probably from your scriptsbut of course, re-using it > > > > would be easier. > > > Sure, no problem. The scripts would need some adjustments. Is the > > > current list the direct output of Thomas' script? Or does it have > > > some manual editing? Can the script be used to keep the packages > > > status updated? Beyond the package list (and some info focus > > > changes) do you think there are other changes needed? > > > > > > If we iron out the details I'll work on the scripts over the weekend. > > > > > > Actually, let's try to get Thomas answer about all this and be sure > > that we're not doing duplicate work. > > > > Thomas, I suggest we work with Lucas so that he can update his old > > scripts to fit our new goal.and you can adjust your extraciton > > scripts so that they keep the list used by Lucas script up-to-date as > > long as the work advances. > > The current output of my script is only HTML (and does not need manual > editing). However, it would be really easy for me to create a database > in the format you think is appropriate, for example: > > Package: foo > Score: 1234 > Debconf: 33, 333444, 44 > L10n: 22, 222333 > > Package: bar > Score: 789 > ... > > And similar entries for every package. Just tell me what would be your > best format and which information I should put in it. You could also > just take my script and copy/paste the interesting part to integrate > this ranking in your pages, so that there are no duplicate sites where > to find the information (or we could do it together). Lucas, did you have time to think about it? Note that I implemented a very basic script to update the status on the page (ITW, NMU...). It is far from having all the feature of the previous infrastructure, but could be used temporarily if somebody wants to start the campaign as soon as possible. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Work started on Release Notes for Etch
Frans Pop <[EMAIL PROTECTED]> (18/09/2006): > On Sunday 17 September 2006 19:57, Yuri Kozlov wrote: > > 2006/9/17, Frans Pop <[EMAIL PROTECTED]>: > > > See [1] for general information on how to get a checkout from the DDP > > > CVS. > > > > http://cvs.debian.org/ddp/manuals.sgml/release-notes/?root=debian-doc&o > >nly_with_tag=etch > > > > Hey, where are .po files ? :) > > po4a is not ready for release-notes sgml ? > > If someone wants to work on this, I have no objection. But IMO the > following conditions should apply: > - don't force translators to use PO files; direct translation of SGML > should be valid too > - warn people about the pitfalls > - make sure that problems generating SGML from a PO file only breaks that > translation and not the whole automated build I've created the few patches needed to integrate po4a in the build process. Everything is available at http://haydn.debian.org/~thuriaux-guest/po4a/ddp/ To activate po4a for your language (condition 1.), you should include Makefile.common.po4a from your /Makefile, by adding the following line: include $(CURDIR)/../Makefile.common.po4a PO files look like (part of condition 2.): release-notes.fr.po This is far from the results of debiandoc2pot. For condition 3.: * Makefile.common.diff is needed, because $(wildcard *.sgml) is evaluated before the sgml file has been generated. * Makefile.diff avoids to stop the whole build if the generation failed. The only constraint is that the original document should be "more valid", especially with conditional inclusions. See for example http://cvs.debian.org/ddp/manuals.sgml/release-notes/en/release-notes.en.sgml?root=debian-doc&r1=1.69&r2=1.70 that fixes some of the problems, and release-notes.en.sgml.diff (not yet committed) fixes the remaining one. Last thing to know: addenda should be added to the /addenda/ directory, with the name .add. They will be automatically included. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Work started on Release Notes for Etch
Frans Pop <[EMAIL PROTECTED]> (18/09/2006): > On Monday 18 September 2006 14:35, Thomas Huriaux wrote: > > The only constraint is that the original document should be "more > > valid", especially with conditional inclusions. > > See for example > > http://cvs.debian.org/ddp/manuals.sgml/release-notes/en/release-notes.e > >n.sgml?root=debian-doc&r1=1.69&r2=1.70 that fixes some of the problems, > > and release-notes.en.sgml.diff (not yet committed) fixes the remaining > > one. > > Hmm. Why are you committing in trunk? > Please read my original mail in this thread. It clearly states that we are > working in a branch for Etch! Hmm sorry, I based my work (which was mainly done one year ago or so) on the version in head. However, it does not hurt, as these fixes remain true. -- Thomas Huriaux signature.asc Description: Digital signature
Re: Work started on Release Notes for Etch
Frans Pop <[EMAIL PROTECTED]> (18/09/2006): > On Monday 18 September 2006 15:07, Frans Pop wrote: > > Hmm. Why are you committing in trunk? > > I have reverted that commit. Not that it is wrong, but because I don't see > any need to make changes to support PO file translations in the Sarge > version of the Release Notes (and run the risk that something > accidentally will fail). No problem, thanks. I have updated the files for the etch branch: http://haydn.debian.org/~thuriaux-guest/po4a/ddp/ Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Work started on Release Notes for Etch
Frans Pop <[EMAIL PROTECTED]> (19/09/2006): > On Monday 18 September 2006 16:16, Thomas Huriaux wrote: > > No problem, thanks. > > I have updated the files for the etch branch: > > http://haydn.debian.org/~thuriaux-guest/po4a/ddp/ > > OK. Thanks. > I must admit that the PO file created by po4a looks a lot more usable than > the one from po-debiandoc. > > A few questions: > - What is the change in release-notes.en.sgml.diff? > I can't see a real change there... There is an unbreakable space hidden between "loaded." and "In". As this is not an ascii char, you have to specify the master document's charset with the -M option of po4a. However, as this char should be a normal space, it's better to fix the document than to add the charset switch. > - Is a POT file created anywhere? How would someone start a new > translation? Or does the "update-po" target handle that as well? Yes, make update-po architecture=foo creates a new PO if it does not exist. Note that the "architecture=foo" switch doesn't change anything if you use "bar" instead of "foo", but is needed due to the very architecture-specific build system of the release-notes. > - Could you add some documentation? Preferably including instructions > how to convert an existing translation to use po4a and how to start > a new translation. I will do that. Is a README text file OK or would you prefer an HTML page (or anything else)? > I am having second thoughts about the patch to the Makefile. The risk is > that errors would not be caught in time as they will be lost in the huge > log for website rebuilds. So, let's try first without that patch. > > When that has been done, I guess the best thing to do would be to file a > wishlist bug report against either debiandoc-sgml or release-notes (not > sure if this should be treated as a general infrastructure thing or a > release notes specific one) so that it can be implemented. OK. > This also means that the machine used to build the website will need po4a > installed. Indeed. The version in sarge is too old (most of the debugging of the sgml module for the ddp has been done post-sarge). The version in etch is ok. Thanks for your comments, -- Thomas Huriaux signature.asc Description: Digital signature
Re: l10n NMU campaign page almost ready
Lucas Wall <[EMAIL PROTECTED]> (20/09/2006): > Christian, Thomas and anybody wishing to help out with this: > > I finished reshaping the scripts and made a test run at my home in > gluck. You can see the page at the same location of the podebconf > campaign[1]. Just a little thing: Are the "NMU Bug" and "WNPP" columns needed? For WNPP bugs (and ftp.debian.org bugs), the maintainer is changed to "Orphaned" (or "Pending for removal") if a "O" (or "RM") bug is detected. Or would you prefer an other field in the status.nmu database? > The daily update cron is not running, but the mail interface should > work. Feel free to test the scripts. When we are all comfortable with > them I will reset and redownload all data. > > Some texts need updating, specially the NMU recommendations page > (process, mail template, etc). Help would be apreciated with that. > > I did not code the ability to override the bug list of packages. Should > I add it? or should we just handle false-positive/negatives by fixing > bug titles? I think retitling the bugs and adding the correct tags is better. Thanks a lot for your work. -- Thomas Huriaux signature.asc Description: Digital signature
Re: l10n NMU campaign page almost ready
Lucas Wall <[EMAIL PROTECTED]> (20/09/2006): > Christian, Thomas and anybody wishing to help out with this: > > I finished reshaping the scripts and made a test run at my home in > gluck. You can see the page at the same location of the podebconf > campaign[1]. > > The daily update cron is not running, but the mail interface should > work. Feel free to test the scripts. When we are all comfortable with > them I will reset and redownload all data. After a few tests, one small bug found: If you send an ITW, the package is correctly assigned, but the status is not updated. See for example the hesiod package (ITW of Christian). I also wanted to clear the "NMU" status for atlas3, but I assume it is not possible to send a "[IGNORE:!]" at this step of the process. For normal IGNORE (e.g. cdebootstrap in the current test page), it could be good to "assign" this status, so that it is easy to find who we should ask to know why this package should be ignored. Cheers, -- Thomas Huriaux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another potential mass bug filing: unused templates?
Christian Perrier <[EMAIL PROTECTED]> (22/09/2006): > > > Quoting Mark Brown ([EMAIL PROTECTED]): > > > > > > Incidentally, your script appears to not pick up on templates that are > > > > just never referenced. Presumably these are generally even more of a > > > > waste of time for translators than low priority notes... > > > Mark Brown pointed me to another interesting target for "mass" bug > filing: checking whether debconf templates defined as translatable in > packages are indeed really used somewhere. > > I'm pretty sure that we can find occurrences of debconf templates that > have been left in package's "templates" files but are no more used by > the packages maintainer scripts (nor by any other package maintainer > scripts). > > That mistake is indeed very easy to dojust remove parts of > maintainer scripts and forget about removing the relevant templates. > > Does anyone feel like playing with scripts to check whether this would > actually be worth it ? Yes, quite similar script as the one for debconf abuse, if you don't consider conditional displays that are never true. I'll do that. -- Thomas Huriaux signature.asc Description: Digital signature
Re: Work started on Release Notes for Etch
Frans Pop <[EMAIL PROTECTED]> (08/10/2006): > On Saturday 07 October 2006 23:13, Jens Seidel wrote: > > > Yes, make update-po architecture=foo creates a new PO if it does not > > > exist. Note that the "architecture=foo" switch doesn't change > > > anything if you use "bar" instead of "foo", but is needed due to the > > > very architecture-specific build system of the release-notes. > > > > Since the Release Notes are architecture specific I loop about all > > architectures to create the PO file. After coding I noticed that > > po4a seems to ignore conditionals, so the loop can maybe removed :-(( > > Not sure why you thought a loop would be needed. po4a will only extract > strings for translations, but add back conditions when regenerating the > sgml file from the po file. The only condition for this to go right is > that the po file must be up-to-date with the English sgml file when > generating the sgml file for the translation. > > I'd say that no loop should be needed other than the loop that already > existed to build all different arches for the website. Indeed, no loop is needed. You only need to specify a random string as the architecture (even a string that is not an architecture, it doesn't matter) to build the PO file. Po4a "ignore" conditionals, i.e. it considers these inclusions as normal tags such as or , which you have to translate if it is inside a paragraph ( Foo bar foo. ) or which you won't see in the PO file if it is outside a paragraph ( Foo bar foo. ). Sorry for not having provided a README file yet, I'm currently very busy. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Re: Advice on template wording
Hi,
Damyan Ivanov <[EMAIL PROTECTED]> (02/12/2006):
> Related to Jens' message[1], please advice on the English wording of the
> following templates I am about to introduce for
> firebird2-{super,classic}-server packages. There are three templates,
> first displayed on new installs, second and third - on upgrades (using
> low priority). The .config script will detect new
> installs/upgrades/reconfigures and either display only the first one, or
> only the second and the third.
>
> Versions up to 1.5.3.4780-11 used a "read" shell function to read the
> password and did not include the explanations.
>
> Thanks in advance for your advice,
> dam
> [1] http://lists.debian.org/debian-i18n/2006/12/msg00013.html
[...]
> = low priority note on upgrades from pre-12 package ==
> Template: firebird2/new_sysdba_password_note
This template is a debconf abuse and should be moved to a NEWS.Debian
file.
> -12 and up re-configures or upgrades, low priority ===
> Template: firebird2/new_sysdba_password
> Type: password
> _Description: Password for SYSDBA:
> Please enter new password for firebird's SYSDBA user.
I would remove this line, it only repeats what is said in the short
description.
Cheers,
--
Thomas Huriaux
signature.asc
Description: Digital signature
Re: Remind/ask DDs to apply translation patches before release? (and ask for new translations at the same time)
Christian Perrier <[EMAIL PROTECTED]> (22/12/2006): > (Removing Daniel from CC) > > > > That would be a great thing to do. Lucas' pages are really great. Although > > I'm not sure the scoring is right, what is it based on? popularity or age? > > Age only, IIRC. > > Using popcon as a ponderation mechanism would definitely be a great > extra feature (while I still think that age is important: it is too > frustrating for translators to see their work being unused). age + popcon, see http://lists.debian.org/debian-i18n/2006/09/msg00058.html for details on how this is processed. -- Thomas Huriaux signature.asc Description: Digital signature
Re: debconf PO translations for the package emdebian-tools
Neil Williams <[EMAIL PROTECTED]> (30/01/2007):
> Question: In my debian/emdebian-tools.config file, I use the title()
> function because I prefer to use the Gnome frontend.
>
> Is it possible to translate the text within the title() function within
> the podebconf handling?
>
> This is my current emdebian-tools.config file:
>
> #!/usr/bin/perl -w
>
> use Debconf::Client::ConfModule qw(:all);
>
> version("2.0");
> my $capb=capb("backup");
> beginblock();
> title("Emdebian SVN coordination");
> input("medium", "emsource/workdir");
> input("medium", "emsource/svnusername");
> endblock();
> go();
Using
settitle("emsource/title");
instead of title() and adding a new template
Template: emsource/title
Type: title
_Description: Emdebian SVN coordination
should do what you want.
Cheers,
--
Thomas Huriaux
signature.asc
Description: Digital signature
Re: debconf PO translations for the package discover
Christian Perrier <[EMAIL PROTECTED]> (18/02/2007): > Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): > > On Fri, Feb 16, 2007 at 10:45:36PM +0100, [EMAIL PROTECTED] wrote: > > > Dear Debian I18N people, > > > > > > I would like to know if some of you would be interested in translating > > > discover. > > > > Which discover program is this? There is already a discover1 package with > > po-debconf translations. Is this a replacement? > > > This is discover2. discover2 (http://packages.qa.debian.org/d/discover2.html) is not in unstable, you are working on discover (http://packages.qa.debian.org/d/discover.html). -- Thomas Huriaux signature.asc Description: Digital signature
Re: Starting a project to review ALL debconf templates in packages
Hi,
Christian Perrier <[EMAIL PROTECTED]> (05/03/2007):
> I would like to propose you (aka Debian translators AND
> debian-l10n-english contributors) a new project. This project has "No
> Name Yet" and is indeed a full debcon templates rewrite/proofread
> project.
>
> Please comment on the project ideaand the process below. Of
> course, proofreading my English is also needed.
I fully support the idea, but I have a few comments (see below).
[...]
>
>Step 1: notify the package maintainer
>to
>
> One of the members of the rewrite team ("the reviewer") notifies the
> package maintainer of the intent to work on the package's templates.
>
> The reviewer sends a message with "[ITT] po-debconf:///en.po"
I would say ITR (Intend to review) instead of ITT (adding tags to the
various bots is a very easy task).
> A 7 days delay is given to the package maintainer to ACK for this
> action or deny it.
Why would you ask for an ACK to submit a wishlist bug proposing an
improvement? I would move this ACK request between step4 and step5
(which would also give time to maintainers to "review the review" before
starting the translation updates).
[...]
>
> Step 4: Send the review to the BTS
>
[...]
>
>Step 5: Call for translation updates
>
[...]
Note also that this action should be coordinated with the debconf
maintainers. The support of the "Note" template is probably going to be
dropped, but I don't know when. If it's early in the release cycle (and
knowing that many of these debconf notes are pointless even in a
NEWS|README.Debian files), it would be a waste of time to review these
templates.
Cheers,
--
Thomas Huriaux
signature.asc
Description: Digital signature
