On Sat, Oct 06, 2001 at 11:23:11AM +0200, Sven Neumann wrote:
> > It's a lot more versatile then the header approach with my lovely
> > friend gettext since the information is not spread over several
> > files which need to be generated, compiled and installed. If we had
> > more tips we could even categorize them.
> I don't think we want all translations in one file.
That wasn't my point. I meant that it might be sensible for tips
(instead of introducing the header kludge) and for plugin descriptions
because it makes them more versatile and not bound to the distribution.
> The file will get large and akward to edit.
In the mentioned case this is not an issue. The tips are pretty small
anyways (just compare it to a uncompiled catalogfile) and for plugins
this isn't an issue at all.
> > Actually using XML would also solve a part of the "how do we localise
> > plugins that are not part of the distribution" problem and might lead
> > to a leaner core distribution and an intelligent repository which is
> > a really cool thing. Back when we implemented the first round of the
> > now active stuff this techniques were not available for consideration
> > and thus we ended with the kludgy solution.
> hmm, how would XML help here and what are the kludgy solutions you speak
> about?
Remember how we solved the localised-menuentries-for-plugins problem?
I'd call it kludgy and it causes trouble for external ones.
So how could it look like? Think glade, it uses XML files to describe
userinterfaces; if we go this way we'll have two choices:
- Create the complete userinterface from XML (including translations).
I'd love to see that because it would ease pluginwriting quite a bit
if we also had good interfaces to access the layerdata directly by
rectangular coordinates also.
- Use the file just for the labels and their translation as well
as for the menuentries; by using a fast library this might also
obsolete pluginrc - simply drop the description in a special
directory and you're all set also for scripts.
> Actually I do have some ideas in this area and I think Ingo wanted
> to outline a plug-in description draft that uses XML.
Cool. I'd like to see it when ready.
> But the use of XML alone will not solve any our problems.
Of course not.
> After all it's only a markup
> language and there's nothing really new to it that you couldn't have done
> years ago.
I tend to disagree; although being available for quite some years now the
tools to use it are still being heavily develloped and were nearly non-
existant back when we last implemented the latest featureset wrt. plugins.
Yes, it's only a markup language but the big advantage is that it's a
standard and well developped and we should make use of that.
--
Servus,
Daniel
