[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Can I commit a fix for a typo for KDE 3.5?
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-11-14 20:21:52
Message-ID: 200511142121.53665.nicolasg () snafu ! de
[Download RAW message or body]

On Monday 14 November 2005 19:39, Nicolas Goutte wrote:
> On Monday 14 November 2005 19:14, Chusslove Illich wrote:
> > > [: Nicolas Goutte :]
> > > - references are sometimes incomplete. (That is already a problem for
> > > KBabel's source context.)
> >
> > Is this a purely technical problem, say to be addressed by the future
> > build system, or is it more complicated?
>
> The problem is that xgettext write paths *relative* to the path where it is
> called.
>
> So you never get what KDE calls the "top subdirectory" and if xgettext is
> not even called from a "top sudirectory" then you lose even more path
> information.
>
> For example in kbabel.pot, you can look that you never have "kbabel" at the
> start of the path.

The example was not that good. As there is a kdesdk/kbabel/kbabel directory, 
some of the entries start with "kbabel" (but not "kbabel/kbabel").

>
> KBabel tries to retrieve that missing information by using the PO file name
> (without extension), but that only works if it is the same name as the
> directory.
>
> However the discussion was about difficult to guess PO files, therefore
> files where KBabel already fails today, because it has not enough
> information.
>
> > > - data files (including .rc, .ui and .kcfg files) are only extracted as
> > > rc.cpp (or similar names) which is not in SVN. [...]
> >
> > But there are already proper references, like this one:
> >
> > #. i18n: file kspread.rc line 16
> > #: rc.cpp:9
> >
> > (Actually, weren't you yourself the one who enabled this?)
>
> The references are incomplete.
>
> xgettext only extract the first special comment that it finds. So you have
> only one reference, not a few ones. But you want to email all authors, not
> only one, to avoid to have an answer like: "But I only did as it was
> already done there."
>
> (Of course, this is a bad example, as it has only a single reference.)
>
> > > But splitting the ways how to report problems to a developer has limits
> > > too. (That is also probably a reason why so many bug categories use a
> > > developer mailing list, to avoid such a split.)
> >
> > Heavens forbid requesting developers to follow yet another stream of
> > information. I proposed raising the developer blamed by SVN directly, but
> > there could also be a list of indirection, like file domain (the part of
> > its path) -> auto bug submission data. This list would be usefull in
> > general, for one could get precise submission data whenever the bug has
> > been isolated to a certain file.
>
> Probably more useful would be a list somewhere in l10n telling which PO(T)
> file is what KDE bug category (and perhaps also with the corresponding
> developer mailing list).
>
> May be we would have to write this file once for 900+ PO(T) files but then
> everybody could see what is what.
>
> (Now we have to think in which format it would be the most useful. Probably
> something in XML, so that it would be still human-readable but
> machine-processable and extensible.)

After thinking, it would be better if such a file was generated 
half-automatically. So probably it is something to add to the new extraction 
system for KDE4. (As probably the POT file name needs to be given separately, 
we could add the mailing list and bug category, right at the extraction rule 
in source.)

>
> Have a nice day!

Have a nice day!

[prev in list] [next in list] [prev in thread] [next in thread]