[RFC] Future of "messages" targets
Nicolas Goutte
nicolasg at snafu.de
Tue Sep 13 14:41:43 BST 2005
On Tuesday 13 September 2005 13:01, Nicolas Goutte wrote:
> On Tuesday 13 September 2005 11:40, Adriaan de Groot wrote:
> > On Tuesday 13 September 2005 11:25, Nicolas Goutte wrote:
(...)
> > A fully automatic approach is to be preferred.
I will try to explain it some more.
>
> It will never be fully automatic, especially when there are data that needs
> to be extracted "by hand".
What I mean here is that there are files that are neither C/C++ files
nor .ui, .rc or .kcfg files.
Such files cannot be extracted automatically. XML files can be extarcted
mostly either by extractrc or extractattr but not with default parameters, as
you have to tell which elements or attributes are needed. (For example Kate's
highlight files or Kontour's stencils).
Also there are non-XML data files, like in KStars were it is a simple text
file (if I remember well).
>
> > Look at the apidox things --
> > there's a single line to add to Makefile.am and the tools figure it out.
> > The existing extractrc stuff should (have) be factored into something
> > like the admin/Doxyfile.am .
>
> I do not mind to simplify the task in long-term but we have now only what
> we have now.
For extracting the user-visible messages, you need to at least know which
directories are going to which POT file.
You cannot let the system guess the name of the POT file, as this will surely
break if the code would be moved. The POT file's name must remain the same as
much as possible, as there are all the translations "behind" it. So renaming
a POT files must be a clear decision and not something automatical.
Similar with directories. You do not know if all sub-directories are to be
extracted too or not, or if yes, which ones. All this depends on the code
(and its history), so again it is not something that can be made automatical.
Doxygen is here different, due to it is very linked to the code and especially
to each classes.
>
> Have a nice day!
More information about the kde-core-devel
mailing list