Asking for a new pseudo package in the BTS: l10n-french
Martin Quinson
sure anymore who decides which pseudo-package exists]
Hello,
As coordinator of the french translation team, we would like to ask for the
creation of a new pseudo package in the BTS. It would be called l10n-french,
and would be made to repport problems in french translations.
It would be possible to repport bugs using the french language. We believe
that a lot of french speaking user can't speak english enough to repport
problems in translations in english, and when they can, developpers may
hesitate about what to do about such bugs.
Using such a pseudo package, users will be able to repport easily such bugs,
tracking such bugs will be easier for team members.
Then, our team can fix by its own problems repported against the web pages,
and we can provide patches to maintainers if the problem is debian specific.
The most interesting case is when the problem is not debian specific. For
now, we have to wait for the debian maintainer to forward the problem to the
upstream author, which have in turn to forward the problem to the
translators working with him. Using the proposed mechanism, the our team
will be able to directly forward the problem to the upstream translators,
which we know in most cases.
Thanks for creating this pseudo module, or for indicating who I should ask
if I'm wrong.
Thanks, Mt.
--
To UNSUBSCRIBE, email to debian-pol...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Adam Heath
Ask ftpmaster, they are responsible. Additionally, I think this pseudo
package is a waste. There is no l10n package, let alone l10n-foo.
Gustavo Noronha Silva
> > Thanks for creating this pseudo module, or for indicating who I should ask
> > if I'm wrong.
>
> Ask ftpmaster, they are responsible. Additionally, I think this pseudo
> package is a waste. There is no l10n package, let alone l10n-foo.
I like the idea. Translators also need to fix their bugs, and there's
currently no centralized (not even a sane =P) way to report bugs on
translations.
I would ask for the creation of l10n-pt_BR if brazilian people would
start trying to report that kind of bugs.
No, mailing lists are not enough for that, it is not an efficient medium
for archiving and stuff.
[]s!
--
k...@debian.org: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br
André Filipe de Assunção e Brito
I think this is a great idea to users help with
translations/translators.
Can we talk about this in i10n-portuguese???
Em Sex, 2003-01-24 às 15:05, Gustavo Noronha Silva escreveu:
> I like the idea. Translators also need to fix their bugs, and there's
> currently no centralized (not even a sane =P) way to report bugs on
> translations.
>
> I would ask for the creation of l10n-pt_BR if brazilian people would
> start trying to report that kind of bugs.
>
> No, mailing lists are not enough for that, it is not an efficient medium
> for archiving and stuff.
>
> []s!
--
André Filipe de Assunção e Brito
decko em #debian-br @ irc.debian.org
ICQ#45427385 / JabberID: de...@jabbet.at
Sitio == http://decko.whg.com.br
Camarada Socialista Engenheiro de Final de Semana
Artista de Rua Tradutor solidário
CIPSGA - Software Livre no Brasil -> http://www.cipsga.org.br
Projeto Debian-BR -> http://www.debian-br.org
"Onde estão os fatos? As boas novas eram só boatos???"
--
To UNSUBSCRIBE, email to debian-i1...@lists.debian.org
Adam Heath
> Em Fri, 24 Jan 2003 09:16:19 -0600 (CST), Adam Heath <ad...@doogie.org> escreveu:
>
> > > Thanks for creating this pseudo module, or for indicating who I should ask
> > > if I'm wrong.
> >
> > Ask ftpmaster, they are responsible. Additionally, I think this pseudo
> > package is a waste. There is no l10n package, let alone l10n-foo.
>
> I like the idea. Translators also need to fix their bugs, and there's
> currently no centralized (not even a sane =P) way to report bugs on
> translations.
>
> I would ask for the creation of l10n-pt_BR if brazilian people would
> start trying to report that kind of bugs.
>
> No, mailing lists are not enough for that, it is not an efficient medium
> for archiving and stuff.
I'm not convinced. Everything you say can be done perfectly well thru mailing
lists.
Martin Quinson
> On Fri, 24 Jan 2003, Gustavo Noronha Silva wrote:
>
> > Em Fri, 24 Jan 2003 09:16:19 -0600 (CST), Adam Heath <ad...@doogie.org> escreveu:
> >
> > > > Thanks for creating this pseudo module, or for indicating who I should ask
> > > > if I'm wrong.
> > >
> > > Ask ftpmaster, they are responsible. Additionally, I think this pseudo
> > > package is a waste. There is no l10n package, let alone l10n-foo.
> >
> > I like the idea. Translators also need to fix their bugs, and there's
> > currently no centralized (not even a sane =P) way to report bugs on
> > translations.
> >
> > I would ask for the creation of l10n-pt_BR if brazilian people would
> > start trying to report that kind of bugs.
> >
> > No, mailing lists are not enough for that, it is not an efficient medium
> > for archiving and stuff.
>
> I'm not convinced. Everything you say can be done perfectly well thru mailing
> lists.
Adam, please, let the translators work. Stop giving useless advices on
something you don't understand.
When will it be possible to show the translated dpkg descriptions to users?
Mt, quite upset.
Javier Fernández-Sanguino Peña
> [debian-i18n CCed for obvious reason, debian-policy CCed because I'm not
> sure anymore who decides which pseudo-package exists]
>
> Hello,
>
> As coordinator of the french translation team, we would like to ask for the
> creation of a new pseudo package in the BTS. It would be called l10n-french,
> and would be made to repport problems in french translations.
I'm not convinced this is a good idea for several reasons. The main
one being that the BTS already holds a place for translation bugs, but that
really depends on what the translation is _about_:
1.- is it a debconf template? then the package that included it should be
bugged.
2.- is it a document that it's included in a package? then the package
should be bugged (sample: doc-debian-fr)
3.- is the document not available in the package? Then file a bug against
debian-doc
4.- is it a manpage? Is it packaged with the program: bug the program, is
it not? bug manpages-XX (XX=es|fr|pt...)
Yes, this might seem overly complicated. It would probably be useful to
have a 'debian-i18n' pseudo-package so that translation coordinators
(subscribed through the PTS) could reassign bugs to the appropiate place
(following the above rule). This should be first created before going on to
create 'debian-i18n-french' or similar ones. IMHO.
I would like you, first, to read the proposal on how to bug documentation
packages (and translations) we've been working on at debian-doc. Please
read http://www.debian.org/doc/manuals/ddp-policy/ch-feedback.en.html
This is not yet policy (it's a draft).
However, I _do_ see the need for a new BTS tag: 'translation'. This could
probably make package maintainer's life easier as well as PTS subscribers
to packages which only want to see translation bugs.
Javi
PS: You can submit your proposals to the DDP-policy as patches, thank you.
Denis Barbier
[...]
> However, I _do_ see the need for a new BTS tag: 'translation'. This could
> probably make package maintainer's life easier as well as PTS subscribers
> to packages which only want to see translation bugs.
Such a tag would be quite useless unless you can tell which language is
targeted, so we need translation-XX tags. IMO we (translation team
coordinators) need a way to receive l10n bugreports related to our
beloved language for all packages, thus having a pseudo-package does
make sense, unless there are better solutions.
Denis
Gustavo Noronha Silva
<j...@computer.org> escreveu:
> On Fri, Jan 24, 2003 at 04:03:39PM +0100, Martin Quinson wrote:
> > As coordinator of the french translation team, we would like to ask for the
> > creation of a new pseudo package in the BTS. It would be called l10n-french,
> > and would be made to repport problems in french translations.
>
> I'm not convinced this is a good idea for several reasons. The main
> one being that the BTS already holds a place for translation bugs, but that
> really depends on what the translation is _about_:
>
> 1.- is it a debconf template? then the package that included it should be
> bugged.
> 2.- is it a document that it's included in a package? then the package
> should be bugged (sample: doc-debian-fr)
> 3.- is the document not available in the package? Then file a bug against
> debian-doc
> 4.- is it a manpage? Is it packaged with the program: bug the program, is
> it not? bug manpages-XX (XX=es|fr|pt...)
That would work if we had official translators for every piece of software,
doc or template we translate. Someone who could keep monitoring his "packages".
Our reality is quite differente... we have quite few translators for a lot
of resources and a centralized way to receive and store translation bugs
is something that would help us a lot.
Michael Brammer helped us a lot by creating the DDTP, it has a nice centralized
bug reporting interface. But still, people need to know how to use the DDTP
to "report a bug".
As reporting bugs to the BTS is already known to lots of users it would help
us a lot if we had a l10n-pt pseudo-package, for example, with
debian-l10n-portuguese as the maintainer.
So, a user could report:
"manpage X on package Y has 'usuários' spelled 'usurios'"
And the translators would quickly know about that bug, and we would have
sane archiving of old and new bugs. If, instead, someone reports this to
the package Y, we would depend on the maintainer doing work for us, and
we already know not all maintainers are helpful on i18n matters =P.
We do not have manpower to monitor lots of bug pages.
> However, I _do_ see the need for a new BTS tag: 'translation'. This could
> probably make package maintainer's life easier as well as PTS subscribers
> to packages which only want to see translation bugs.
That would help, but a 'translation' bug could happen in any language,
and it would suck having to browse translation bugs for all languages
to find bugs reported on mine.
[]s!
--
k...@debian.org: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br
Andrew Suffield
On Mon, Jan 27, 2003 at 08:51:45AM +0100, Martin Quinson wrote:
> On Sun, Jan 26, 2003 at 08:49:15PM -0600, Adam Heath wrote:
> > On Fri, 24 Jan 2003, Gustavo Noronha Silva wrote:
> >
> > > Em Fri, 24 Jan 2003 09:16:19 -0600 (CST), Adam Heath <ad...@doogie.org> escreveu:
> > >
> > > > > Thanks for creating this pseudo module, or for indicating who I should ask
> > > > > if I'm wrong.
> > > >
> > > > Ask ftpmaster, they are responsible. Additionally, I think this pseudo
> > > > package is a waste. There is no l10n package, let alone l10n-foo.
> > >
> > > I like the idea. Translators also need to fix their bugs, and there's
> > > currently no centralized (not even a sane =P) way to report bugs on
> > > translations.
> > >
> > > I would ask for the creation of l10n-pt_BR if brazilian people would
> > > start trying to report that kind of bugs.
> > >
> > > No, mailing lists are not enough for that, it is not an efficient medium
> > > for archiving and stuff.
> >
> > I'm not convinced. Everything you say can be done perfectly well thru mailing
> > lists.
>
> Adam, please, let the translators work. Stop giving useless advices on
> something you don't understand.
Right back at you.
That mail contained nothing but an unsubstantiated flame, roughly
equivalent to "I'm right, you're wrong, now do what I say". Did you
really expect it to persuade people to do stuff?
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ | Dept. of Computing,
`. `' | Imperial College,
`- -><- | London, UK
Martin Quinson
> On Mon, Jan 27, 2003 at 08:51:45AM +0100, Martin Quinson wrote:
> > On Sun, Jan 26, 2003 at 08:49:15PM -0600, Adam Heath wrote:
> >
> > > I'm not convinced. Everything you say can be done perfectly well thru
> > > mailing lists.
> >
> > Adam, please, let the translators work. Stop giving useless advices on
> > something you don't understand.
>
> Right back at you.
>
> That mail contained nothing but an unsubstantiated flame, roughly
> equivalent to "I'm right, you're wrong, now do what I say". Did you
> really expect it to persuade people to do stuff?
You're right. I did not argument my point of view a second time since Adam
didn't answer to it, just using « i'm not convinced » as argument. So, I
used the terse flame style I learned on debian-dpkg ;)
I guess that if you missed some previous discution I had with Adam on
helping translators to do their job, my mail can look pretty stupid and
denote a lack of maturity.
(ok, i agree that even if you saw those discutions, you may come to the same
conclusion ;)
Thanks for your attention, Mt.
Martin Quinson
First of all, I changed my mind a bit, and now think that the right name for
the pseudo package to be created should be qa-<language>, with the language
name being written with all letters, not iso code. I guess that it will make
clear for maintainer what it is good for, and is easy enough to remeber for
users (IMHO).
On Mon, Jan 27, 2003 at 01:54:25PM -0200, Gustavo Noronha Silva wrote:
> Em Mon, 27 Jan 2003 14:06:09 +0100, Javier Fernández-Sanguino Peña
> <j...@computer.org> escreveu:
>
> > On Fri, Jan 24, 2003 at 04:03:39PM +0100, Martin Quinson wrote:
> > > As coordinator of the french translation team, we would like to ask for the
> > > creation of a new pseudo package in the BTS. It would be called l10n-french,
> > > and would be made to repport problems in french translations.
> >
> > I'm not convinced this is a good idea for several reasons. The main
> > one being that the BTS already holds a place for translation bugs, but that
> > really depends on what the translation is _about_:
> >
> > 1.- is it a debconf template? then the package that included it should be
> > bugged.
> > 2.- is it a document that it's included in a package? then the package
> > should be bugged (sample: doc-debian-fr)
> > 3.- is the document not available in the package? Then file a bug against
> > debian-doc
> > 4.- is it a manpage? Is it packaged with the program: bug the program, is
> > it not? bug manpages-XX (XX=es|fr|pt...)
>
> That would work if we had official translators for every piece of software,
> doc or template we translate. Someone who could keep monitoring his "packages".
For that, we need that dpkg supports some translator-XX: fields, and
something like proposed in
http://lists.debian.org/debian-devel/2001/debian-devel-200108/msg02329.html
to be implemented. But for now, it looks like science-fiction to me.
> Our reality is quite differente... we have quite few translators for a lot
> of resources and a centralized way to receive and store translation bugs
> is something that would help us a lot.
>
> Michael Brammer helped us a lot by creating the DDTP, it has a nice centralized
> bug reporting interface. But still, people need to know how to use the DDTP
> to "report a bug".
And bugs against the DDTP can't port on manpages or web pages, or did I miss
something?
> As reporting bugs to the BTS is already known to lots of users it would help
> us a lot if we had a l10n-pt pseudo-package, for example, with
> debian-l10n-portuguese as the maintainer.
>
> So, a user could report:
>
> "manpage X on package Y has 'usuários' spelled 'usurios'"
They could even repport against qa-french something like
« la page de manuel X du paquet Y orthographie 'errreure' au lieu de 'erreur' »
No other system but a specialized pseudo-package can allow the users to
repport translation bug in their own language.
> And the translators would quickly know about that bug, and we would have
> sane archiving of old and new bugs. If, instead, someone reports this to
> the package Y, we would depend on the maintainer doing work for us, and
> we already know not all maintainers are helpful on i18n matters =P.
>
> We do not have manpower to monitor lots of bug pages.
Agreed. And even more, maintainers faced to a translation bug could reassign
the bug to the corresponding qa-xxxx package, then the translators provide a
patch and reassign it to the original package for patch integration.
> > I would like you, first, to read the proposal on how to bug documentation
> > packages (and translations) we've been working on at debian-doc. Please
> > read http://www.debian.org/doc/manuals/ddp-policy/ch-feedback.en.html
> >
> > This is not yet policy (it's a draft).
I did read this proposal, and it looks very good for documentation issues.
FYI, we already send ITT mails on the debian-l10n-french, but we never
trusted ourselves to send them as bug against the WNPP, since most of the
time those mails are in french, and we don't want to polute the already
heavily loaded WNPP bug page with our cruft. As result, we have no list of
made ITT, and I guess than some of them were forgotten.
I do not agree with the following sentence of your proposal: "Translators
<em>must</em> be subscribed to the BTS for the translated package versions."
It's already hard enough to recruit translators and reviewers, but if I ask
them to monitor a whole bunch of unrelated bug repports, it's an impossible
task. The remark of Gustavo about lacking manpower applies well here.
The graph at the end of the chapter seems to suffer of buggy
TAB-to-space-conversion.
Moreover, this graph do not take the updating of translation when original
is update into account. You may want to check po4a for that. Such a graph is
presented at:
http://www.nongnu.org/po4a/#graphical_summary
As a conclusion, I *think* you should remove everything about translation
from this proposal, since what you say here is not enough, and wait until we
agree on methods shared by all teams on this list before we try to document
them.
I naturally tend to think that po4a may be a really usefull tool here. ;)
http://savannah.nongnu.org/projects/po4a
> > However, I _do_ see the need for a new BTS tag: 'translation'. This could
> > probably make package maintainer's life easier as well as PTS subscribers
> > to packages which only want to see translation bugs.
>
> That would help, but a 'translation' bug could happen in any language,
> and it would suck having to browse translation bugs for all languages
> to find bugs reported on mine.
I already asked for this tag, back in october 2001. This is #114221.
But AJ was not convinced, and since no translators gave their advice, I
convinced myself that I was wrong. Now, a year and half after, I tend to
agree with Gustavo. Such tag could be helpfull, but that's not the
definitive solution. I guess i'll close my old bug repport.
Bye, Mt.
--
If the facts don't fit the theory, change the facts.
-- Albert Einstein
--
To UNSUBSCRIBE, email to debian-i1...@lists.debian.org
Osamu Aoki
> To sum up my point, the best solution would be that translators become the
> same status inside Debian than maintainers.
If we have enough qualified ones, .. yes always but I doubt it.
> One way to achieve that is that binary packages would contain not only
> data.tar.gz, but also data-XX.tar.gz (and maybe doc-XX.tar.gz, but that's
> another point), one for each language. Then, building a binary package would
> build all parts. So, when the maintainer release a version, he release the
> whole stuff. Then, translator would be provided a way to overide the data-XX
> part with updated translation. That's a bit what's proposed in
> http://lists.debian.org/debian-devel/2001/debian-devel-200108/msg02329.html
I think what you proposed can be done through recommends and separate
binary packages. I mean that we can make new packages which only has
translated document or catalog for message to localize the
internationalized package if translated document maintainer is DD. I
understand some advantage for this.
But this will strain current package archive with huge number of
packages. My P-233MHz is sluggish when checking dependencies already
and my DX4-50 MHz requires me to go to bed before getting dependency
check finishes.
I think we need some fundamental packaging management system change
before we do things like this. I mean who want to set manually all
translated document is selected or deselected.
> I agree that there is still a lot of design issues with that approach (what
> will be the package version when a translation is updated?), but if we could
> get this working, it would be the best.
>
>
> As long as this solution isn't effective (ie a loooong time), we have to
> search for tricks.
>
> One possible trick is to create a pseudo-package for each translation team
> (this pseudo-package could be named qa-<language), and allow bug repport
> against it to:
> 1) allow bug repport in the local language, and not english
> 2) allow translators to see immediatly bugs of their work, without asking
> them to monitor all the bugs of all the packages they translate.
This is quite doable provided followings are met.
1) Package maintainer is first line of contact.
2) README.Debian in the package explains pseudo-package qa-<language>
3) Source for localized translation is in CVS.debian.org .
4) Packager or upstream if it wishes always get latest translation from
pseudo-package qa-<language> CVS.
5) If Package maintainer get bug report, it reassign bug with some
special tag (BTS should deal it like upstream tag, I guess.)
> Another trick is a 'translation' tag for the BTS (see #114221). Also
> useful (with PTS, translators could subscribe to all translation bugs of
> packages they translate), but not as much as the first trick, since:
> - I'm not sure of the maintainers' reaction when they see a bug in french
> with the "translation" tag.
French is not big issue but Japanese UTF-8 or EUCJP mail will likely get
dropped by SPAM filter :-(
> - translator will get all translation bugs, not only the ones for their
> language. Could be overcome by the creation of many 'translation-XX'
> tags, but is this what we want?
>
>
> Proposed solutions which does not work well IMHO:
> - keep as we are: bugs are reported against the package containing it:
> every translation team have to have the needed manpower to monitor *all*
> bugs submitted against *all* Debian package.
> - keep as we are, but use the 'upstream' tag for translations issues.
> That means that translators are denied the use of the BTS and have to
> handle bugs without the corresponding tools.
So pseudo package will solve it :-)
> - don't use the BTS, but the bug tracking system from the DDTP:
> works only for pkg descriptions, debconf templates (?), and so, but not
> for man pages, program messages, and so on.
I am not sure but Japanese man page is a separate package. So it is not
a issue.
> - http://www.debian.org/doc/manuals/ddp-policy/ch-feedback.en.html
> This is specifically designed for documentation, but does not take
> several translation issues into account.
Well, I think ddp-policy will be narrowing scope to get approval. But
we should keep discussing best infrastructure for feed back for package
specific documentation.
> Here we are. Now, there is two solutions. Either each team continue to
> search its own trick on its side, and we continue to hack like we do now, or
> we do speak between translation coordinators to see which solution could be
> developped, and we try to organize ourselves as a debian-l10n team, using
> the same well designed methods for the well known issues.
I think coordinated effort with DDP and DDTP will be nice.
Osamu
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
Osamu Aoki <os...@debian.org> Cupertino CA USA, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
Michael Bramer
> On Thu, Feb 13, 2003 at 01:31:17AM +0100, Michael Bramer wrote:
> [...]
> > The i10n packages have real package maintainers, we have a real
> > BTS-package. Also we can make new i10n packages, without any delay from
> > the bin package maintainer.
>
> I would like to insist on the difficulies to join the Debian project
> as translators. Not beeing consider as a DD mean that every time one
> needs to submit a translation on a cvsroot, he has to find a kindly
> proxy who will submit the l10n files.
I don't see any problem, if we use a DDTP like system for the
translation. Everybody can translate some text, everybody can review the
translation and the 'packages' are build on the fly (without any delay
from some normal package maintainers and all this binary buildd's)
As normal translator/reviewer you don't need to join the Debian project.
But you can. Some packages with a working upstream translation
group/service (like KDE, GNOME, ...) can't join a Debian system. They
need some normal translation Maintainer, who get the translations from
the upstream and make normal packages.
But we must avoid the dependence of the translator from the binary
packages maintainers! This is IMHO one big problem today.
> That's why I believe that Martin's idea to create an entry into the
> BTS is the nice idea.
and you must wait for the binary packages maintainers... Not nice...
(we should make this BTS packages/tags today, it is a improvement, but
in future we should make a better system...)
> > Some translator can build a own aptable http server with his newest
> > translations and maybe some DDTP-like system can build daily new i10n
> > packages, if it has new translations...
>
> Is that too difficult to 'build' l10n-package on the fly ? What I mean is
> that once you've choosen your language, apt could pick out the l10n
> files from a kind of repository.
if s/files/packages/ then ACK
Gruss
Grisu
--
Michael Bramer - a Debian Linux Developer http://www.debsupport.de
PGP: finger gr...@db.debian.org -- Linux Sysadmin -- Use Debian Linux
"Ziemlich viele Firmen, die alle kein Linux benutzen, würden nach Abschaltung
der Linux-Rechner erst mal ins Schwimmen kommen." -- Matthias Peick
Michael Bramer
> On Thu, Feb 13, 2003 at 05:15:07PM +0100, Michael Bramer wrote:
> [...]
> > > clear about that, and I seem to remember that you still translate debconf
> > > templates of the old generation, ie, the ones handled by debconf-utils.
> >
> > you can btw test the first files, see
> > http://ddtp.debian.org/debconf/template_unstable/base-config/templates-de.po
>
> There are several problems:
> * all msgids have a trailing space
> * msgids are not unique
> * encoding is not specified
Oh, I know this all. This are the first files..., I will add/change this
points. This was no announcement of the availability of po files.
> But the main problem is that you are extracting templates from binary
> packages, and not source packages. This is exactly as if you were
Maybe I should change the source from binary packages to source
packages. The nice point with the binary packages is: You can find the
templates all on the some place in all packages.
If I use the source, the server must search the templates and guess it.
And maybe the template file will be change with some patch files etc.
in some packages build scripts.
> translating messages by running msgunfmt on .mo files. You are losing
> comments written by previous translators.
and?
Maybe the DDTS is not compatible with this po like comments. But is this
a problem? IMHO no.
My dream:
The package maintainer make only 'his' english templates file and
upload the package to the archive.
The DDTP will catch all this new stuff, translate it all in 1-2 weeks
automagical into all languages.
If the package maintainer make a new build, some build scripts
download the translations from the DDTP and include this to this
package (the old system) or the DDTP make a XXX-i10n-XX package itself
and upload this with all the translation.
You get the point? We don't need comments in the po files! The po file
is only a container for the transport from the DDTP to the binary
package. Nobody will look into it. Nobody will read this comments...
Gruss
Grisu
--
Michael Bramer - a Debian Linux Developer http://www.debsupport.de
PGP: finger gr...@db.debian.org -- Linux Sysadmin -- Use Debian Linux
Documentation is is like sex; bad documentation is much better than
no documentation.
Denis Barbier
[...]
> > * all msgids have a trailing space
> > * msgids are not unique
> > * encoding is not specified
>
> Oh, I know this all. This are the first files..., I will add/change this
> points. This was no announcement of the availability of po files.
I thought you were asking for feedback, sorry for the trouble.
[...]
> > translating messages by running msgunfmt on .mo files. You are losing
> > comments written by previous translators.
>
> and?
>
> Maybe the DDTS is not compatible with this po like comments. But is this
> a problem? IMHO no.
You also lose fuzzy strings, __Choices is not supported, etc.
> My dream:
> The package maintainer make only 'his' english templates file and
> upload the package to the archive.
> The DDTP will catch all this new stuff, translate it all in 1-2 weeks
> automagical into all languages.
> If the package maintainer make a new build, some build scripts
> download the translations from the DDTP and include this to this
> package (the old system) or the DDTP make a XXX-i10n-XX package itself
> and upload this with all the translation.
>
> You get the point? We don't need comments in the po files! The po file
> is only a container for the transport from the DDTP to the binary
> package. Nobody will look into it. Nobody will read this comments...
Your point is that everything works wonderful if the DDTP is the only
source of l10n. Sorry but this is not acceptable, translators can
decide to manage their translations in a different way.
What you describe is mostly a clone of the Free Translation Project,
but information is centralized by the DDTS whereas it is distributed
in PO files by the FTP. This is IMO a huge difference, I much prefer
the latter.
Denis
Michael Bramer
> On Fri, Feb 14, 2003 at 03:31:08AM +0100, Michael Bramer wrote:
> [...]
> > > There are several problems:
> > > * all msgids have a trailing space
> > > * msgids are not unique
> > > * encoding is not specified
> >
> > Oh, I know this all. This are the first files..., I will add/change this
> > points. This was no announcement of the availability of po files.
>
> I thought you were asking for feedback, sorry for the trouble.
no trouble...
> > > translating messages by running msgunfmt on .mo files. You are losing
> > > comments written by previous translators.
> >
> > and?
> >
> > Maybe the DDTS is not compatible with this po like comments. But is this
> > a problem? IMHO no.
>
> You also lose fuzzy strings, __Choices is not supported, etc.
We don't need fuzzy in DDTP.
If the text changed, the DDTP make a bug report and the last translator
get this, with the old, the new English text and the old translation.
The old translation is removed from the translated file, and after the
upload of the new translation, the ddts insert the new translation in
the translated file.
to the Choices:
this is still true.
1.) Only <5% of all tempelates have translateable Choices
2.) The DDTP will support this in future. (But other things are on
the top of my TODO list.)
> > My dream:
> > The package maintainer make only 'his' english templates file and
> > upload the package to the archive.
> > The DDTP will catch all this new stuff, translate it all in 1-2 weeks
> > automagical into all languages.
> > If the package maintainer make a new build, some build scripts
> > download the translations from the DDTP and include this to this
> > package (the old system) or the DDTP make a XXX-i10n-XX package itself
> > and upload this with all the translation.
> >
> > You get the point? We don't need comments in the po files! The po file
> > is only a container for the transport from the DDTP to the binary
> > package. Nobody will look into it. Nobody will read this comments...
>
> Your point is that everything works wonderful if the DDTP is the only
> source of l10n. Sorry but this is not acceptable, translators can
> decide to manage their translations in a different way.
yes, you right. The translators can get the normal po files and use
this. No translator must use the DDTP framework. The DDTP is only a
offer for translators and reviewer.
If a package A has some translators, and this translators make the
translations, send this to the package maintainer of A and he use this
translation, all is ok. Nobody will of this will use the DDTP. This is
ok.
But the real live is differently. See the graphic from
http://ddtp.debian.org/debconf/gnuplot/ddts-stat.png:
At the beginning from 2000 debconf descriptions, we have only 700
translated into German. Some of this translations are outdated. All this
is not very nice.
Now we have 2300 translations of 3000 debconf translations. And this all
in 5 Months. And the DDTP avoid outdated translation and the review
process give some quality.
short: If the maintainer and the translator work without the DDTP all is
ok. But if the maintainer and the translator (and the reviewer)
use the framework of the DDTP, the don't need any comments, fuzzy
flags etc. in the debconfs files from the DDTP.
> What you describe is mostly a clone of the Free Translation Project,
> but information is centralized by the DDTS whereas it is distributed
> in PO files by the FTP. This is IMO a huge difference, I much prefer
> the latter.
1.) IMHO I know the TP (I never work with it)
2.) The TP is only for normal po files. I don't find any other po files
there (like the debconf templates po files, po from man pages, ...)
3.) gettext avoid outdated translations, but IMHO TP don't inform the
translator about changes etc.
4.) I don't like to translate text from normal programs (like tar),
programs with own translation system (like KDE) or something like this.
The DDTP will only support
- first debian only texts (like Package Description, Debconf
templates, ...)
- maybe sometimes other 'extern' texts, if nobody other make a
translation.
Nobody must use the DDTP. If you prefer other ways, make your work like
you prefer ways.
Gruss
Grisu
--
Michael Bramer - a Debian Linux Developer http://www.debsupport.de
PGP: finger gr...@db.debian.org -- Linux Sysadmin -- Use Debian Linux
"Das Schlimme am Pessimismus ist eigentlich, meistens Recht zu
bekommen." -- Michael Olbricht in dasr
Pierre Machard
[...]
> 3.) gettext avoid outdated translations, but IMHO TP don't inform the
> translator about changes etc.
On that very point it's not true, for example, as a PO contributor
I recieve that kind of email :
This email comes with a Subject which is very nice :
Subject: texinfo-4.3c (99%, 4 untranslated)
-----------------------------------------------------------------------------
Hello, members of the French team at `trad...@traduc.org'. This is a
message from the Translation Project robot. I'm happy to announce that
a new file, available as:
> http://www.iro.umontreal.ca/contrib/po/teams/PO/fr/texinfo-4.3c.fr.po
has been integrated in the central PO archives, and is now kept with
all other accepted French translations. The file should soon be made
available in mirror sites as:
> ftp://ftp.unex.es/pub/gnu-i18n/po/teams/PO/fr/texinfo-4.3c.fr.po
> http://translation.sf.net/teams/PO/fr/texinfo-4.3c.fr.po
> ftp://tiger.informatik.hu-berlin.de/pub/po/teams/PO/fr/texinfo-4.3c.fr.po
In this file, 543 messages have been translated already, accounting
for 99% of the original text size (in raw bytes). Still, 4 messages
need to be attended to. Laurent Bourbeau is currently assigned for
the translation.
Please translate the remaining messages for the benefit of users of the
French language. Once the translation completed, send the result to
the address given below, using the Subject line:
> TP-Robot texinfo-4.3c.fr.po
in your message header. You may contact either your team leader or me,
if any question arises. In the meantime, this PO file has been
submitted
to the maintainer of programs using the textual domain `texinfo'.
Thanks!
-----------------------------------------------------------------------------
Cheers,
--
Pierre Machard
<pmac...@tuxfamily.org> TuxFamily.org
<pmac...@techmag.net> techmag.info
+33(0)668 178 365 http://migus.tuxfamily.org/gpg.txt
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87
Michael Bramer
> [...]
> > 3.) gettext avoid outdated translations, but IMHO TP don't inform the
> > translator about changes etc.
>
> On that very point it's not true, for example, as a PO contributor
> I recieve that kind of email :
Thanks for this info.
Gruss
Grisu
--
Michael Bramer - a Debian Linux Developer http://www.debsupport.de
PGP: finger gr...@db.debian.org -- Linux Sysadmin -- Use Debian Linux
"Now let me explain why this makes intuitive sense." --- Prof. Larry Wasserman
Denis Barbier
[...]
> The package maintainer make only 'his' english templates file and
> upload the package to the archive.
> The DDTP will catch all this new stuff, translate it all in 1-2 weeks
> automagical into all languages.
> If the package maintainer make a new build, some build scripts
> download the translations from the DDTP and include this to this
> package (the old system) or the DDTP make a XXX-i10n-XX package itself
> and upload this with all the translation.
Here is an alternative. I am not telling that l10n must be done this
way, but IMO it is worth a try.
Imagine that the DDTP builds debconf template databases instead of templates
files (i.e. /var/cache/debconf/templates.dat) for each single language
(in order to keep each file small), say templates.dat-xx where xx is
language code. These templates.dat-xx contain the templates in English
and in the xx language for all packages which have debconf templates
localized in this language.
Now on your machine retrieve the desired languages and put them at a
specific location:
mkdir -p /var/cache/debconf-l10n/de/
mkdir -p /var/cache/debconf-l10n/fr/
cp templates.dat-de /var/cache/debconf-l10n/de/templates.dat
cp templates.dat-fr /var/cache/debconf-l10n/fr/templates.dat
and modify /etc/debconf.conf to load those localized databases before
templatedb; replace
Name: templatedb
Driver: File
Mode: 644
Filename: /var/cache/debconf/templates.dat
by
Name: templatedb-debconf
Driver: File
Mode: 644
Filename: /var/cache/debconf/templates.dat
Name: templatedb-de
Driver: File
Mode: 644
Filename: /var/cache/debconf-l10n/de/templates.dat
Readonly: true
Name: templatedb-fr
Driver: File
Mode: 644
Filename: /var/cache/debconf-l10n/fr/templates.dat
Readonly: true
Name: templatedb
Driver: Stack
Stack: templatedb-fr, templatedb-de, templatedb-debconf
and that's it, you have access to all fr and de translations.
Michael Bramer
(I cc to joeyh)
Have you try it? Will it work?
Maybe joeyh can give some comments...
Gruss
Grisu
--
Michael Bramer - a Debian Linux Developer http://www.debsupport.de
PGP: finger gr...@db.debian.org -- Linux Sysadmin -- Use Debian Linux
Since software cannot be foolproof, we should get rid of the the
fools.
Denis Barbier
[...]
>
> Have you try it?
Yes.
> Will it work?
Yes it works out of the box if your localized templates.dat files
are up to date.
Again I am not telling that debconf must be l10n-ed this way, but
you can test it if you want to use your own translations without
waiting for Debian developers to include them in their packages.
Denis
Michael Bramer
> On Sat, Feb 15, 2003 at 08:24:27AM +0100, Michael Bramer wrote:
> [...]
> > > and that's it, you have access to all fr and de translations.
> >
> > Have you try it?
>
> Yes.
>
> > Will it work?
>
> Yes it works out of the box if your localized templates.dat files
> are up to date.
ok, I test it mayself.
some comments:
- it need debconf from testing. older debconf have problems with reonly
db on top of the stack (no big thing)
- the minium for the translated debconf dat file is:
Name: debconf/frontend
Description-de: (test) Welche Schnittstelle soll zum Konfigurieren der Pakete verwendet werden?
Extended_description-de: (test) Pakete die Debconf für die Konfiguration verwenden teilen ein gemeinsames »look and feel«. Sie können wählen, welches User-Interface sie benutzen.\n\nDas Dialog-Frontend ist ein symbolzeichenbasiertes vollbildschirm Interface, das Readline-Frontend verwendet ein traditionelleres Text-Interface und das Gnome-Frontend ist ein modernes X-Interface. Das Editor-Frontend läßt Sie Dinge mit Ihrem Lieblingseditor konfigurieren. Das nichtinteraktive Frontend stellt ihnen keine Fragen.
Owners: debconf/frontend
sorry for the long lines.
What is 'Owners'? It must be in the file (or you get: "Can't call
method "clearall" on an undefined value at
/usr/share/perl5/Debconf/Template.pm line 150")
It is all the time equal with 'Name'?
- The debconf dat file don't need the english text. This is IMHO a big
problem. Not only for us. You get all the time the text from the
stack top db!
Joey please thought about this:
- someone use a stacked debconf config with some central debconf
datas (with defaults) and one privat one.
- in both db's are all Infos from package foo
- he update this package
- the central debconf db is readonly, the package foo has some new
templates and change some old ones.
- debconf show the text of the old template from the central debconf
db.
- But maybe the changes in the text of the new package version are
important
You see the problem?
If the maintainer change the meaning of a template or add/change
important notes, he must use a other templates name!
- /etc/debconf.conf is a conffile. The user must change it by hand or
we need a update-debconf command or debconf should include a config
with i10l support (with 'Required: false'). Comments?
- I like the l10n-ed of debconf templates with this way in generally.
Maybe I should make some denconf-l10n-XX packages with all
translations into XX and we make a big test.
Comments?
> Again I am not telling that debconf must be l10n-ed this way, but
> you can test it if you want to use your own translations without
> waiting for Debian developers to include them in their packages.
It is not the best way, but it is very interesting.
Thanks for the hint
Gruss
Grisu
--
Michael Bramer - a Debian Linux Developer http://www.debsupport.de
PGP: finger gr...@db.debian.org -- Linux Sysadmin -- Use Debian Linux
Windows ist der One-Night-Stand unter den Betriebssystemen. Man fühlt
sich so billig, wenn man es benutzt hat. -- Illiad in uf
Eduard Bloch
* Michael Bramer [Thu, Feb 13 2003, 01:31:17AM]:
> gmc-i10n-es (all translations for the bin-package gmc (po, man-pages,
> README-files, ...)
> gmc-i10n-de
> gmc-i10n-fr
> gmc-i10n-..
>
> The bin package 'gmc' have a 'Suggests: gmc-i10n-*' like dependence and
> the user can use apt pining to avoid some languages.
Not the best idea, IMO. If someone with good C++ knowledge has some
spare time, she should try to implement the conditional dependencies in
APT.
Gruss/Regards,
Eduard.
--
Wir haben gerade gelernt, daß nicht jeder ein Autowerk
an seinem Rechner angeschlossen hat.
-- Thomas Uwe Grüttmüller
Martin Quinson
> #include <hallo.h>
> * Michael Bramer [Thu, Feb 13 2003, 01:31:17AM]:
>
> > gmc-i10n-es (all translations for the bin-package gmc (po, man-pages,
> > README-files, ...)
> > gmc-i10n-de
> > gmc-i10n-fr
> > gmc-i10n-..
> >
> > The bin package 'gmc' have a 'Suggests: gmc-i10n-*' like dependence and
> > the user can use apt pining to avoid some languages.
>
> Not the best idea, IMO. If someone with good C++ knowledge has some
> spare time, she should try to implement the conditional dependencies in
> APT.
Does it have a chance to get integrated in apt, or will it be yet another
i18n rotting patch ?
Thanks, Mt.
--
Or, bien souvent, les matières scientifiques ne se discutent pas. Il y a une
logique d'acquisition des savoirs qui nécessitent plus de « par coeur » que
de créativité.
--- Luc Ferry, Ministre français de l'éducation nationale.