Re: Installer Translation Status
Quoting Frans Pop (elen...@planet.nl): Basing on debcommit seems the only correct option to me. Possibly a fallback to stripped epoch could be used to cover current cases. Actually, the best solution is probably to simply rename the tags in SVN to include the epoch using 'svn mv'. Being the origin of the problem, I can do that. So far, I identifier apt-setup and tzsetup as the only D-I packages with an epoch (recursively going through directories with debian/changelog and run 'dpkg-parsechangelog | grep -E ^Version:.*:.*'). Any reason to make this change on other packages? signature.asc Description: Digital signature
Re: Installer Translation Status
Basing on debcommit seems the only correct option to me. Possibly a fallback to stripped epoch could be used to cover current cases. Actually, the best solution is probably to simply rename the tags in SVN to include the epoch using 'svn mv'. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007202029.41669.elen...@planet.nl
Installer Translation Status
Hello, I just uploaded installer without updating the translation-status file. I did it because I didn't figure the reason why versions aren't matching with the script. One package, that is the quik-installer, is due the NMU but others looks to have been tagged without the epoch and this confuses the script. It looks like debcommit put the epoch by default so the packages lacking the epoch might have been tagged byhand; since I do plan a new installer upload soon I did not hold it until we sorted it out but wanted to inform the list about the issue. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilv91ukeev32tt1vlvx5bujafhfl7ysbffvd...@mail.gmail.com
Re: Installer Translation Status
Quoting Otavio Salvador (ota...@ossystems.com.br): Hello, I just uploaded installer without updating the translation-status file. I did it because I didn't figure the reason why versions aren't matching with the script. One package, that is the quik-installer, is due the NMU but others looks to have been tagged without the epoch and this confuses the script. It looks like debcommit put the epoch by default so the packages lacking the epoch might have been tagged byhand; since I do plan a new installer upload soon I did not hold it until we sorted it out but wanted to inform the list about the issue. The packages I released were tagged with the attached script, contributed by Joey back in.a long time ago..:-) Apparently, it does strip the epoch when calculating the tag. I guess this was on purpose. #!/bin/sh -e # Commit changes, using the current changelog as the message. if [ -d CVS ]; then PROG=cvs elif [ -d .svn ]; then PROG=svn else echo not in a cvs or subversion directory 2 exit 1 fi echo Committing with $PROG ... if [ $1 = release ] [ -e debian/changelog ]; then if head -1 debian/changelog | grep -q UNRELEASED; then echo Changelog says it's UNRELEASED, bud. exit 1 fi version=`dpkg-parsechangelog | grep Version: | cut -f 2 -d ' '` $PROG commit -m releasing version $version debian/changelog fi if [ $PROG = svn ]; then # use new part of changelog as commit entry MSG=$(svn diff debian/changelog | grep '^\+ ' | sed 's/^+//') if [ -n $MSG ]; then $PROG commit -m $(svn diff debian/changelog | grep '^\+ ' | sed 's/^+//') else $PROG commit -m `dpkg-parsechangelog | grep '^ '` fi else # cvs is too slow for that $PROG commit -m `dpkg-parsechangelog | grep '^ '` fi if [ $1 = release ]; then # Generate the tag. This is compatable with the tag cvs-buildpackage # uses except for debian native packages. newversion=`expr $version : '[0-9]:\(.*\)'` 2/dev/null || true if [ $newversion ]; then version=$newversion fi if [ -d CVS ]; then # escape tag for cvs if [ `expr $version : '.*-.*'` -gt 0 ]; then tag=debian_version_$version else tag=version_$version fi tag=`echo $tag | tr . _` cvs tag -f $tag elif [ -d .svn ]; then tag=$version echo svn copy $(svnpath) $(svnpath tags)/$tag if ! svn copy $(svnpath) $(svnpath tags)/$tag -m tagging version $version; then echo svn mkdir $(svnpath tags) svn mkdir $(svnpath tags) -m create tag subdirectory echo svn copy $(svnpath) $(svnpath tags)/$tag svn copy $(svnpath) $(svnpath tags)/$tag -m tagging version $version fi fi fi signature.asc Description: Digital signature
Re: Installer Translation Status
Hello, On Mon, Jul 19, 2010 at 2:51 PM, Christian PERRIER bubu...@debian.org wrote: The packages I released were tagged with the attached script, contributed by Joey back in.a long time ago..:-) Apparently, it does strip the epoch when calculating the tag. I guess this was on purpose. Yes but it breaks calc-translation-status and also conflicts with debcommit behaviour; I think we need to decide which one is to be the used format (with or without epoch). In my opinion debcommit behaviour looks right and we ought to use epoch specially because we can end up with same version in two different epochs without it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilsadjohv_dnuz86v8j1lfn1wqjxgfqmk2ud...@mail.gmail.com
Re: Installer Translation Status
On Monday 19 July 2010, Otavio Salvador wrote: On Mon, Jul 19, 2010 at 2:51 PM, Christian PERRIER bubu...@debian.org wrote: The packages I released were tagged with the attached script, contributed by Joey back in.a long time ago..:-) Apparently, it does strip the epoch when calculating the tag. I guess this was on purpose. Yes but it breaks calc-translation-status and also conflicts with debcommit behaviour; I think we need to decide which one is to be the used format (with or without epoch). In my opinion debcommit behaviour looks right and we ought to use epoch specially because we can end up with same version in two different epochs without it. Basing on debcommit seems the only correct option to me. Possibly a fallback to stripped epoch could be used to cover current cases. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007192101.45980.elen...@planet.nl
Re: Installer Translation Status
Quoting Frans Pop (elen...@planet.nl): Basing on debcommit seems the only correct option to me. Possibly a fallback to stripped epoch could be used to cover current cases. Agreed for me. I'll also fix my script. I might still be using it for quite a while until I figure out how to use debcommit for release stuff*and* think about using it. I'm on the right way as I'm more and more using debcommit rather than do manual commits signature.asc Description: Digital signature
Re: Installer Translation Status
On Mon, Jul 19, 2010 at 4:13 PM, Christian PERRIER bubu...@debian.org wrote: Quoting Frans Pop (elen...@planet.nl): Basing on debcommit seems the only correct option to me. Possibly a fallback to stripped epoch could be used to cover current cases. Agreed for me. I'll also fix my script. I might still be using it for quite a while until I figure out how to use debcommit for release stuff*and* think about using it. I'm on the right way as I'm more and more using debcommit rather than do manual commits There's no black magic involved; just: debcommit --release -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik8gcwyzt-2so4nfwjautonqqljdaknaotnr...@mail.gmail.com
Re: [l10n] Debian Installer translation status
Quoting Nikolai Prokoschenko ([EMAIL PROTECTED]): On Thu, Apr 22, 2004 at 01:43:58AM +0200, Denis Barbier wrote: We can then expect 36 fully translated languages in beta4, and even more if other languages work really very hard. When 1st stage is over, translators should focus on 2nd stage or installation manual (no statistics yet on this manual). It would be really nice then, if the outstanding translations for console-data could be committed to SVN then - or SVN write access is given. For example, Russian translation is complete (with one fuzzy ATM), except for console-data, which had a bug with a patch submitted yesterday evening. I have a pending commit for them. However, it sems that I'm currently unable to commit to console-data SVN repository...:-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] Debian Installer translation status
Hi, * Denis Barbier [2004-04-22 01:43:58+0200] [...] 2nd stage: popularity-contest tasksel base-config console-common iso-codes[1] exim4 pcmcia-cs shadow newt [1] Should be listed in 1st stage [...] * 8 partially translated ( 50%) [...] Turkish Turkish translations of above packages except exim4 have already been submitted. But some of them has still been waiting for the maintainer's action (i.e. 'shadow/po'). This explains the lower stats and I think the same situation exists for the other languages. These statistics were extracted from http://people.debian.org/~seppy/d-i/translation-status.html which contains many more useful informations for translators. FYI, though I performed a debconf-updatepo here, I couldn't confirm the given statistics of shadow-4.0.3/debian/po/tr.po: 16t10f0u, (it seems %100 here). -- roktas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Er: Re: [l10n] Debian Installer translation status
action (i.e. 'shadow/po'). This explains the lower stats and I think the same situation exists for the other languages. Yes, basque translations of all 2-stage files was submitted. And some fot the 3-stage too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] Debian Installer translation status
On Thu, Apr 22, 2004 at 10:59:04AM +0300, Recai Oktas wrote: [...] These statistics were extracted from http://people.debian.org/~seppy/d-i/translation-status.html which contains many more useful informations for translators. FYI, though I performed a debconf-updatepo here, I couldn't confirm the given statistics of shadow-4.0.3/debian/po/tr.po: 16t10f0u, (it seems %100 here). When no access to SVN/CVS is provided, stats are computed on uploaded packages and does not take patches sent to BTS into account. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[l10n] Debian Installer translation status
Hi there, as you know we are in a string freeze for d-i beta4. Two new packages have been added to SVN repository (mdcfg and partman/partman-md) but their templates.pot are not considered because they won't be in beta4. Another change is about console-data, its stats have been moved from 2nd stage to 1st stage, because its templates are used by kbd-chooser. This change was planned for a long time, but I managed it only today, so this explains why many languages are at 99% whereas they were fully translated in beta3. 1st stage: all d-i packages plus console-data * 12 full translations Basque Brazilian Portuguese Czech Danish Dutch French German Hebrew Hungarian Portuguese Turkish Ukrainian * 19 nearly complete translations ( 90%) Albanian Catalan Chinese (Simplified) Chinese (Traditional) Finnish Galician Greek Indonesian Italian Japanese Korean Lithuanian Norwegian Bokmal Norwegian Nynorsk Polish Romanian Russian Slovakian Swedish * 5 translations in good shape ( 75%) Bosnian Bulgarian Slovenian Spanish Welsh We can then expect 36 fully translated languages in beta4, and even more if other languages work really very hard. When 1st stage is over, translators should focus on 2nd stage or installation manual (no statistics yet on this manual). 2nd stage: popularity-contest tasksel base-config console-common iso-codes[1] exim4 pcmcia-cs shadow newt [1] Should be listed in 1st stage * 11 nearly complete translations ( 90%) Chinese (Simplified) Czech Danish Dutch French German Greek Japanese Korean Portuguese Slovenian * 2 translations in good shape ( 75%) Ukrainian Polish * 8 partially translated ( 50%) Basque Brazilian Portuguese Finnish Hungarian Lithuanian Russian Spanish Turkish Galician, Indonesian and more especially Basque are very well ranked despite these are new translations, congratulations to all of you. And eventually, translators should definitely try to test beta4, this is the only way to make sure that translations are well suited for the given context. These statistics were extracted from http://people.debian.org/~seppy/d-i/translation-status.html which contains many more useful informations for translators. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] Debian Installer translation status
On Thu, Apr 22, 2004 at 01:43:58AM +0200, Denis Barbier wrote: We can then expect 36 fully translated languages in beta4, and even more if other languages work really very hard. When 1st stage is over, translators should focus on 2nd stage or installation manual (no statistics yet on this manual). It would be really nice then, if the outstanding translations for console-data could be committed to SVN then - or SVN write access is given. For example, Russian translation is complete (with one fuzzy ATM), except for console-data, which had a bug with a patch submitted yesterday evening. -- Nikolai Prokoschenko [EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[l10n] Debian Installer translation status
As several of you have noticed, this week-end was quite busy, especially the last hour before Joey uploaded final packages for beta3 of the Debian Installer. After the final hurry, we ended up with the following situation for Debian Installer localisation: 25 full translations (all d-i packages plus base-config plus tasksel): Albanian Brazilian Portuguese Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Czech Danish Dutch Finnish French German Greek Hungarian Japanese Korean Lithuanian Norwegian Bokmal Norwegian Nynorsk Portuguese Russian Slovakian Turkish Ukrainian Welsh 3 nearly full translations (very few strings missing, most of them not often used) Italian Spanish Slovenian (only one string missing in base-config. tasksel will be OK) 4 partial translations (most often very partial partman translations) Arabic Bosnian Polish Swedish 2 work in progress (translations started very late and couldn't make it in time for beta3) Hebrew Romanian This is a huge improvement since beta2 where we had: 9 full translations 10 nearly full 3 partial 9 work in progress The current target for Debian Installer is 34 languages. (for two of them, Hebrew and Arabic, they will however be unusable as long as BIDI support is not implemented in newt...as we can't expect a GTK interface very soon, imho) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] Debian Installer translation status
After the final hurry, we ended up with the following situation for Debian Installer localisation: I hereby thank all people who participate in Debian Installer translation work. The work method improved significantly during the beta2-beta3 time period. Now, nearly all language coordinators (this title is quite informal) have CVS commit access, which speeds up the process significantly. For d-i translators who still do NOT have such write access to debian-installer, base-config, tasksel repositories, please ask me and I'll do what's needed. The current weaknesses I can identify in our l10n process: -changelog updates : this is still a real pain. Nikolai scripts improved the work but some glitches remain: -in the scripts for detecting which translations were updated -adding an UNRELEASED entry is sometimes forgotten -several translations teams are currently made of one single translator. This is an evident weakness and I encourage people to build their own team, including using a debian-l10n-x mailing list -1st stage/2nd stage packages : Dennis Stampfer has working stuff for all this. This will improve soon - several 2nd stage packages do not use CVS, or use their own private CVS (or SVN). We should encourage maintainers to move to Alioth and give translators CVS (or SVN) write access -identical strings in partman : something should be done for this as this is really annoying for translators. The worst are *nearly* identical strings -we were pressured by time so the string freeze was very short. Some teams got lost with that (italian, spanish...). This is likely to happen again for future release(s), so I encourage these teams to more closely follow strings changes. This sometimes means reworking the same strings -the boot/root floppies now cannot handle all translations. Joey went into this problem. We have to deal with this, probably by removing duplicated strings (each duplicated string seems to cost a few kb) -we need ALL translators to follow debian-boot. I proposed a dedicated mailing list but several translators weren't enthusiast about it. So, PLEASE, at least use a [l10n] marker for l10n issues in debian-boot -we still miss some important languages in the world (Hindi, Indonesian, Afrikaans or other ZA languages, African languages) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [l10n] Debian Installer translation status
On Mon, Mar 15, 2004 at 10:52:13AM +0100, Christian Perrier wrote: (stuff deleted) -identical strings in partman : something should be done for this as this is really annoying for translators. The worst are *nearly* identical strings Agreed. Specially annoying for those not using translation programs with catalog support. -we were pressured by time so the string freeze was very short. Some teams got lost with that (italian, spanish...). This is likely to happen again for future release(s), so I encourage these teams to more closely follow strings changes. This sometimes means reworking the same strings I really believe that if there is a string freeze it should be anounced here, not on debian-boot. -we need ALL translators to follow debian-boot. I proposed a dedicated mailing list but several translators weren't enthusiast about it. So, PLEASE, at least use a [l10n] marker for l10n issues in debian-boot No, PLEASE don't force translators to read yet another list. It wouldn't be so difficult to CC: debian-l10n-* in the l10n messages or, even, CC: debian-i18n? Since the d-i work is being done by many translation teams the later might even be more reasonable. In any case, I don't expect people that develop a program to force me to subscribe to their development mailing list to notice when there is a string freeze. As a translator, I expect forewarning either directly to my own e-mail address or through a dedicated mailing list. If you help force this model you are giving an excuse for others developments teams (dpkg? apt? X?) to force translators to keep track of yet another mailing list. Either make a d-i-l10n mailing list in Alioth (it should be rather easy) with the current translator coordinators or send the messages to d-l10n in CC: Regards Javier signature.asc Description: Digital signature
Re: [l10n] Debian Installer translation status
Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): No, PLEASE don't force translators to read yet another list. It wouldn't be so difficult to CC: debian-l10n-* in the l10n messages or, even, CC: debian-i18n? Since the d-i work is being done by many translation teams the later might even be more reasonable. Well, I wasn't particularly glad to ask translators follo -boot and, anyway, I can't force anyone to do anything...:-). Translation worked very well until them with a very informal structure so let's keep it informal, for sure. My preferences goes to a dedicated mailing list dor d-i l10n. I also thought about the other part of your suggestion (using -i18n). However I imagined that this could botther people using and reading -i18n for other purposes. The third choice is using a dedicated d-i-l10n mailing list. Your proposal for an alioth ML is interesting, indeed. However, when pinging translators individually, I felt some of them relectant to following another ML. Mostly, people wo don't want another ML are people who also participate in d-i coding. Specialized translators are in favour of a dedicated ML. I, for myself, am a bit balanced:-) BTW, Javi : will you go to debconf4? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
