Re: Wrong quote characters in finnish translation of installer guide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tapio Lehtonen wrote: > In web page > http://d-i.alioth.debian.org/manual/fi.i386/ch01s03.html > the quote characters surrounding > > troijalaisilta > > are not the quote characters normally used in Finnish, namely " as > beginning and ending quote. That is because the xsl transformation is not aware of that. You should: 1) be sure that what you say is correct :-) 2) send a patch to upstream (package docbook-xsl) Note: I have sent such a patch for Romanian, but I am waiting for the fixed version to reach Debian. > See > http://www.ling.helsinki.fi/filt/info/mes2/merkkien-nimet.html > in chapter 2.1 Suomi. > - -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFINQFY8Chqv3NRNoRAgCpAJ9FRvuxkEnMvXATrSwdqu7MmF5rsACeNUTG GlS47o44IqDOzqzrBhx7qEs= =Lj1n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] translating via an intermediate language
Hi Bruno, On Thursday at 13:51, Bruno Haible wrote: > The syntax for a mixed PO file could like this: > > msgid "Hello, world!" > msgid[ru] "Здравствуй, мир!" > msgstr "Chào thế giới !" I think the following would make more sense (except that the syntax would conflict plural forms syntax): msgid "Hello, world!" msgstr[ru] "Здравствуй, мир!" msgstr[vi] "Chào thế giới !" I know that some may still feel this is English-centered (which it is), but we can then even have things like: msgid "Hello, wrld!" msgstr[en] "Hello, world!" msgstr[ru] "Здравствуй, мир!" msgstr[sr] "Здраво свете!" msgstr[vi] "Chào thế giới !" Now, this might make people expect changes to MO format as well, but we can instead transform single PO to multiple MO files. And there would be a problem that some developers might start using this container-PO format for all translations, which would be crap for translators if they have to extract and merge their stuff, watching for conflicts with others, etc. So, that's the big risk I see with an approach like this: it's too tempting to put all translations in there, which is where your suggestion beats this one. Another thing to be careful about is many-to-one-to-many mappings, eg. what if both "Blah" and "Foo" translate to something like "Bar" in language "trt": msgid "Blah" msgid[trt] "Bar" msgstr ... msgid "Foo" msgid[trt] "Bar" msgstr ... And we use "trt" as our base language, then "Bar" is clearly not a unique msgid, which is exactly why I feel msgstr there makes more sense. (as a sidenote, I already have a working PHP and gettext-based system which does gettext_in_alternate_language(msgid) instead of displaying msgid; this can simply be done in PO tools with pointers to two PO files: "use this one for base messages, translate into this one") > The PO file editors would have to be taught to display msgid[ru] in preference > to msgid if the translator has said so. And I think it's no more work to ask them to simply support reading translations from another PO file and use that in place of msgid's. Cheers, Danilo
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, Oct 02, 2006 at 12:54:13AM +0200, Michael Vogt wrote: > On Wed, Sep 27, 2006 at 11:42:35PM -0700, Steve Langasek wrote: > > On Thu, Sep 28, 2006 at 02:35:19AM -0300, Otavio Salvador wrote: > > > > On Wed, Sep 27, 2006 at 07:13:21PM +0200, Luk Claes wrote: > > > >> Would you still accept an ABI change of apt to support description > > > >> translations into etch? > > That's why I considered it so late for uploading to unstable. I didn't > wanted to upload it without real-world testing because of the risk of > having to break the ABI yet again to fix mistakes in the code. > > We may have to recompile the rdepends of libapt anyway because of > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390189 > (recent g++ upload 4.1.1ds1-14 has a g++ regression) Debian was always proud because of many software packages. Nevertheless it's a real drawback that package descriptions are only available in English. Many person with no English skills do not know the packages Debian provides and ignored these because of this. Once I installed a system with translated package descriptions for a friend I remember first time users of Debian browsing description just for fun, testing these packages, comparing with other systems, ... Without they never touched aptitude and complained about the usability. Consider how many people whould profit from it! Ten thousands, hundred thousands of users?! Please compare this with possible disadvantages and choose the proper solution! Once it enters testing I would also ask additional users from various lists (not only developers) to properly use and test it and would be willing to help these users to report possible problems. I'm sure many other people (translators and other) would do the same once you consider the changes for Etch. I now subscribed also to the APT bugs and will try my best ... Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, 2006-10-02 at 11:54 +0200, Jens Seidel wrote: > Consider how many people whould profit from it! I'm missing the following practical note a bit in this discussion: are there actually a significant number of translations to take the non-trivial venture of a very late apt update? I value the importance of the DDTP project, but the translating effort has only recently seriously started. Looking at the statistics[1], I see that the best language has yet only one third of descriptions translated in optional and extra, and steeply dropping to only a couple of percentpoints for those after that. Best translated are required/important/standard, but those descriptions will be the least relevant to Joe Average, since these packages are already installed for him. Concluding, we will not be able to claim that Debian has "translated package descriptions", except for a very small number of languages. I think it's not worth the effort to risk delay or trouble for this; let's focus on other areas in etch now and make sure etch+1 has a really comprehensive set of translated descriptions. Thijs signature.asc Description: This is a digitally signed message part
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, Oct 02, 2006 at 12:54:13AM +0200, Michael Vogt wrote: > > BTW, I count 18 binary packages that would need a rebuild for this. This is > > a decent-sized library transition in its own right. > We may have to recompile the rdepends of libapt anyway because of > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390189 > (recent g++ upload 4.1.1ds1-14 has a g++ regression) This version of g++-4.1 hasn't been accepted into etch yet, and there's been no request from Matthias that we do so. Letting it into etch as a freeze exception suggests that we might have *other* packages fail to build as a result of similar ABI regressions in other libraries. That doesn't sound like a good idea to me unless someone is offering to do a full regression-test of testing using g++ 4.1.1-15. > Upstream gcc bugreport: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29289 >From this report, there's nothing to suggest the reverse-deps need to be rebuilt, only that the lib needs to be rebuilt so that the reverse-deps don't FTBFS. Is there something I'm missing? > Matthias is still waiting for a comment from upstream on this. It > maybe enough to recompile apt with the current g++, but it maybe that > the only save option is to change the soname and recompile a rdepends. If there really is reason to believe this requires an soname change, I think we should instead consider backing this patch out of g++-4.1 in unstable until after the etch release, as compiler-induced ABI changes are clearly *not* supposed to be happening during a toolchain freeze. > > > There's no API changes from APT side so just binary NMUs are enough > > > AFAIK. > > So what is this ABI change that doesn't involve API changes? > There is a API change involved. But it is backwards compatible so a > recompile will be good enough. To make use of the translated > descriptions the applications needs to be changed though. Patches are > available for aptitude, python-apt, synaptic, libapt-front (0.3). > I hope this helps and I'm sorry for the bad timing with this request :/ FWIW, this didn't answer the question "what is the ABI change?" :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] [translate-pootle] gettext with non-en source language
On 2 oct. 06, at 21:08, Bruno Haible wrote: I foresee a possible scenario for example where someone in francophone Africa writes in French which will be the common language to use to translate into local languages. Not the best choice to get you translations in all the world's languages, perhaps, but the correct choice for their circumstances. I'm speaking quite hypothetical now, of course. Quite hypothetical, indeed. Africa is not yet connected to the programmer's net. I got a single mail from Africa in 14 years. (Not counting the masses of Nigeria connection spam :-)) Maybe you are not on the right lists. Making an estimate of localization needs based on the number of people who get in touch with you in English (or any other language you use) is certainly not a statistically proven method. There is tremendous localization activity in African countries (not limited to South Africa) and other developer-poor areas. See Javier Sola's work in Cambodia. Of course, people who work on localization create pools of users and developers who do not need to communicate in English. Do you see a lot of Chinese developers on the net expressing themselves in English ? If you do are they not only the tip of an "iceberg" of Chinese only (or close) developers who do not feel the need to share with English only (or close) developers ? Jean-Christophe Helary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, Oct 02, 2006 at 01:17:18PM +0200, Thijs Kinkhorst wrote: > On Mon, 2006-10-02 at 11:54 +0200, Jens Seidel wrote: > > Consider how many people whould profit from it! > > I'm missing the following practical note a bit in this discussion: are > there actually a significant number of translations to take the > non-trivial venture of a very late apt update? > > I value the importance of the DDTP project, but the translating effort > has only recently seriously started. Looking at the statistics[1], I see See http://ddtp.debian.net/ for this link [1]. > that the best language has yet only one third of descriptions translated > in optional and extra, and steeply dropping to only a couple of > percentpoints for those after that. > > Concluding, we will not be able to claim that Debian has "translated > package descriptions", except for a very small number of languages. I > think it's not worth the effort to risk delay or trouble for this; let's > focus on other areas in etch now and make sure etch+1 has a really > comprehensive set of translated descriptions. Right. Nevertheless there are currently already at least 4 languages with (partly many more than) 1000 package descriptions. Also consider that the translation effort is independent of the Etch release (external database, no package upload are required, except of course for apt). Up to the release of Etch (for CD based installations) or even after it (network connection) users could profit from it. I can also guarantee that the effort will increase dramatically once we know that APT would support it. Currently the matra is: "Let's ignore package descriptions as these will probably not be usable in Etch at all". Once users see a incomplete project they want to help, right!? Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Announce of the upcoming NMU for the dokuwiki package
Dear maintainer of dokuwiki and Debian translators, On September 29th, I sent a notice to the maintainer of the dokuwiki Debian package, about a fix I wanted to apply to dokuwiki's templates and to call for translations for it. I announced the intent to build and possibly upload a non-maintainer upload for this package. The package maintainer approved this NMU so I will start building it now. The package is currently translated to: cs de es fi fr sv vi The following translations are incomplete: cs de es fi fr sv vi (even after applying pending l10n bugs, of course) If you did any of the, currently incomplete, translations you will get a copy of this announcement BCCd to you. Please review the translation. Other translators also have the opportunity to create new translations for this package. Once completed, please send them directly to me so I can incorporate them into the package being built. The deadline for receiving updates and new translations is 09 Oct 2006. If you are not in time you can always send your translation to the BTS. You can download the pot, and any po, files from: http://people.debian.org/~lwall/i18n/pots/dokuwiki If the maintainer objects to this process I will immediately abort my NMU and send him/her all updates I receive. Otherwise the following will happen (or already has): 29 Sep 2006 : send the first intent to NMU notice to the package maintainer. 02 Oct 2006 : post a NMU announcement to debian-i18n with you (maintainer) CC'ed 09 Oct 2006 : deadline for receiving translation updates 11 Oct 2006 : build the package and upload it to DELAYED/2-day send the NMU patch to the BTS 13 Oct 2006 : NMU uploaded to incoming 14 Oct 2006 : NMU enters unstable Thanks for your efforts and time. -- adn Mohammed Adn??ne Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [translate-pootle] [Translation-i18n] gettext with non-en source language
F Wolff wrote:
> > What you call "gettext's English-centredness" is only a recommendation
> > in the doc. You _can_ use another language as the language of the source
> > files and the msgids in the PO files. Did you try it? Did you encounter
> > problems?
>
> Well, I did not try it, but the example used here (Czech as source
> language) won't work, because it has three plural forms.
Good point. But this problem can be overcome by defining a function
const char *
cz_ngettext (const char *singular, const char *paucal, const char *plural,
unsigned long n)
{
const char *translation = ngettext (singular, plural, n);
if (translation == singular || translation == plural)
return (n == 1 ? singular : n >= 2 && n <= 4 ? paucal : plural);
else
return translation;
}
then using cz_ngettext in the source code, and finally passing the option
--keyword=cz_ngettext:1,3 to xgettext.
> I foresee a possible scenario for example
> where someone in francophone Africa writes in French which will be the
> common language to use to translate into local languages. Not the best
> choice to get you translations in all the world's languages, perhaps,
> but the correct choice for their circumstances. I'm speaking quite
> hypothetical now, of course.
Quite hypothetical, indeed. Africa is not yet connected to the programmer's
net. I got a single mail from Africa in 14 years. (Not counting the masses
of Nigeria connection spam :-))
> Although it would be interesting to see how
> many people will be able to contribute for the first time if
> understanding of English is removed as obstacle.
That appears to depend on the country's culture or economic situation. There
must be good knowledge of English in India, yet there are reportedly only
7 free software developers in whole India.
Bruno
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] gettext with non-en source language
Jean-Christophe Helary wrote: > In the next decades and starting very soon, the world's most > understood languages will be Chinese and Hindi, and especially those > two will have a huge influence on the IT world. And only the people > who don't read Chinese on Hindi are blind to that. > > It is very short sighted to not take that into account. Chinese and Hindi the most understood languages of the world? I doubt that. Languages have in the past spread 1. through conquests, 2. through culture (music, literature, cinema, ...). China (PRC) is an aggressive state (*), but IMO it will not conquer the U.S. nor Europe in the next 50 years; and India is not an aggressive state. Chinese culture is mostly unknown in the rest of the world. Indian culture spreads out, but very slowly; Bollywood will take a long time to replace Hollywood. The influence of languages is large in IT world if 1. the language is wide-spread in general, or 2. the language is wide-spread in IT, or 3. the top computer scientists come from a culture that speaks this language. Neither the Chinese nor the Hindi language fits these criteria. Bruno (*) Don't forget that 3000 students were murdered by the government of the "People's Republic of China" in June 1989! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wrong quote characters in finnish translation of installer guide
On Monday 02 October 2006 10:56, Eddy Petrișor wrote: > Tapio Lehtonen wrote: > > In web page > > http://d-i.alioth.debian.org/manual/fi.i386/ch01s03.html > > the quote characters surrounding > > > > troijalaisilta > > > > are not the quote characters normally used in Finnish, namely " as > > beginning and ending quote. > > That is because the xsl transformation is not aware of that. You > should: 1) be sure that what you say is correct :-) > 2) send a patch to upstream (package docbook-xsl) > > Note: I have sent such a patch for Romanian, but I am waiting for the > fixed version to reach Debian. > > > See > > http://www.ling.helsinki.fi/filt/info/mes2/merkkien-nimet.html > > in chapter 2.1 Suomi. Eddy is correct. See also the file: /usr/share/xml/docbook/stylesheet/nwalsh/common/fi.xml That is where the relevant definitions are. Cheers, FJP pgpvjlYpsxujK.pgp Description: PGP signature
Re: Would an ABI change of apt for DDTP support still be accepted?
On 10/2/06, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: I value the importance of the DDTP project, but the translating effort has only recently seriously started. Looking at the statistics[1], I see that the best language has yet only one third of descriptions translated in optional and extra, and steeply dropping to only a couple of percentpoints for those after that. Not sure which statistics you're looking at, perhaps these? [1] Sure, maybe the top language has only 33% of optional done, but several languages cover the entire base install. Additionally, the numbers are not fixed. As many (most?) descriptions are shared between etch and sid, even after etch is released the descriptions will keep getting updated and improved. Best translated are required/important/standard, but those descriptions will be the least relevant to Joe Average, since these packages are already installed for him. The goal should be making sure that most of the packages people have installed are translated, as well as the most popular packages. That is a much more acheivable goal, and I think that's attainable in the near future... I hope you're not suggesting we need to get all languages covering all of optional before you think it is worthwhile? As for whether it's enough to make it happen for etch, that's not my call. But the vast majority of descriptions for etch+1 will be usable for etch also, so the decision should *not* be based on whether the descriptions are ready now. Have a nice day, [1] http://svana.org/kleptog/temp/ddts-stats.html -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] translating via an intermediate language
Hello Clytie, > Another translator has > already mentioned doing this in Emacs: keeping the backup language PO > file as a reference. So if we could request: > > msgid[en] > msgid[xx] > msgstr > > in an editor, specifying the secondary msgid language in the prefs, ... It can not be done purely in the editor. Because if, say, the Russian translator updates her translation, correcting a mistake she did in an earlier translation, and you translate from Russian to Vietnamese, you need to be alerted of this. msgmerge needs to set the 'fuzzy' flag when this happens. If it were just the editor which displays a synthesis of vi.po and ru.po, this could not work. We really need to save a (partial) copy of ru.po in vi.po. > Current candidates for the secondary msgid language, which would > increase our translation resources, and make it possible for many > more translators to participate, include Russian, Spanish, > Portuguese, French, Afrikaans, Chinese and Hindi. Absolutely! Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] translating via an intermediate language
Hi Danilo, > > The syntax for a mixed PO file could like this: > > > > msgid "Hello, world!" > > msgid[ru] "Здравствуй, мир!" > > msgstr "Chào thế giới !" > > I think the following would make more sense (except that the syntax > would conflict plural forms syntax): > >msgid "Hello, world!" >msgstr[ru] "Здравствуй, мир!" >msgstr[vi] "Chào thế giới !" The syntax could be reconciled with plurals. There is no problem writing msgstr[fr][0] "singulier" msgstr[fr][1] "pluriel" But this syntax has two drawbacks: - It doesn't make it clear whether 'ru' or 'vi' is the target language. Whereas the syntax with msgid[ru] makes it more clear what is the input for the translator and where she puts her translation. - As you mentioned, there is a risk that people confuse it with a "multi-language PO file". > Another thing to be careful about is many-to-one-to-many mappings, > eg. what if both "Blah" and "Foo" translate to something like "Bar" in > language "trt": > > msgid "Blah" > msgid[trt] "Bar" > msgstr ... > > msgid "Foo" > msgid[trt] "Bar" > msgstr ... > > And we use "trt" as our base language, then "Bar" is clearly not a > unique msgid, which is exactly why I feel msgstr there makes more > sense. There is no uniqueness requirement for msgid[trt], indeed. In a case like this, the translator would have to look at the msgid line too, not only at her preferred msgid[trt] line. > (as a sidenote, I already have a working PHP and gettext-based system > which does gettext_in_alternate_language(msgid) instead of displaying > msgid; this can simply be done in PO tools with pointers to two PO > files: "use this one for base messages, translate into this one") Interesting! And what are the practical experiences you or translators made with it so far (except that it's useful :-))? Bruno
Re: [Translation-i18n] translating via an intermediate language
Hi Bruno, Today at 18:12, Bruno Haible wrote: > Interesting! And what are the practical experiences you or translators > made with it so far (except that it's useful :-))? Well, both positive and negative. The biggest negatives: some had problem actually finding the relevant strings in the UI, since it was not so predictable anymore (i.e. you have to use same language in the UI as well, and what seem like "original" strings may change underneath you); it also became a bit confusing when some strings were not translated in the "alternate base" language, so they got the English string, but this was well documented behaviour so it didn't cause much problems. ;) As for the positives, except for being useful ;), it also allowed me to actually develop in English, while multilingual users (translators) were expected to be mostly familiar with Esperanto (except for the notable few whose main task was to translate my English to Esperanto) or any other language. The project never ended up being finished (lack of coordination between two groups: developers and target users), so there was not too much practical experience (only intimate members of the team worked with this, and we all know they are not useful for usability studies ;). What has been developed so far has been done under GPL, so once I clean-up some parts which shouldn't be public, I'll also publish entire CMS as well. ;) Cheers, Danilo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
On Mon, Oct 02, 2006 at 01:17:18PM +0200, Thijs Kinkhorst wrote: > On Mon, 2006-10-02 at 11:54 +0200, Jens Seidel wrote: > I value the importance of the DDTP project, but the translating effort > has only recently seriously started. Looking at the statistics[1], I see The first DDTP translation effort started years ago (over 4, actually) and it was quite serious at the time for some languages. It was stalled due to gluck's compromise and recently restarted. > that the best language has yet only one third of descriptions translated > in optional and extra, and steeply dropping to only a couple of > percentpoints for those after that. This is very much related to the fact that the language teams see no gain for translating the DDTP right now since end-users would not be able to see them, as there is no support in apt or its frontends. A change in apt to make those visible when users run 'apt-cache search|show' even if apt frontends (aptitude, synaptic) do not use them yet would certainly make translation teams shift their efforts over to the DDTP. Just my 2c. Javier signature.asc Description: Digital signature
Re: Would an ABI change of apt for DDTP support still be accepted?
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes: > On Mon, Oct 02, 2006 at 01:17:18PM +0200, Thijs Kinkhorst wrote: >> On Mon, 2006-10-02 at 11:54 +0200, Jens Seidel wrote: >> I value the importance of the DDTP project, but the translating effort >> has only recently seriously started. Looking at the statistics[1], I see > > The first DDTP translation effort started years ago (over 4, actually) and it > was quite serious at the time for some languages. It was stalled due to > gluck's compromise and recently restarted. And my first APT patch was release in 2003[1]. As anyone can notice, it's not new. 1. http://lists.debian.org/debian-devel-announce/2003/04/msg00015.html -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house."
DDTSS, reviewed descriptions and login
Hi Martijn, I reviewed a package description as usual but this time I logged in via my account (jensseidel). I noticed that my reviews do not move from "Pending review" to "Reviewed by you" so that I have to remember which packages I already reviewed. I can reselect such a checked package and the script recognizes me as owner, so it seems to work. Just the display is not optimal ... Can you please fix it? It would also nice to have the package account mapping available, so that we can honour the most active people ... Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DDTP on packages.debian.org
On Mon, Oct 02, 2006 at 08:48:39PM +0200, Javier Fernández-Sanguino Pe?a wrote: > > This is very much related to the fact that the language teams see no gain for > translating the DDTP right now since end-users would not be able to see them, > as there is no support in apt or its frontends. BTW, at some point of time the translations were used on http://packages.debian.org, which is not the case anymore. Does anybody know what happened and if it can be corrected? -- Miroslav Kure -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
