[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 18:39:04
Message-ID: 200511141939.04885.nicolasg () snafu ! de
[Download RAW message or body]

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.

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.)

Have a nice day!

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