Hi, Daniel Egger <degger@xxxxxxxxxxxxxxxxx> writes: > > > 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. I was referring to the tips and nothing but the tips. > > 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. I disagree. The english tips file has about 180 lines, with XML markup it will grow a little. At the moment there are 26 languages in ALL_LINGUAS. This would mean that the file would grow to over 5000 lines. To edit your language, you'd most probably have to have two editor views open since you won't be able to get the original tip and your translation on the same page. A second problem is encodings. There aren't many good UTF-8 capable editors out there and if you have all translations in one file, you can't easily convert to your native encoding for editing. As a translator, I'd prefer to have the original version in one file and edit a po file created from that source. If I am informed correctly, this is what most GNOME programs do or plan to do these days and there's a bunch of developer tools available for this purpose in the intltool module in GNOME CVS. > Remember how we solved the localised-menuentries-for-plugins problem? > I'd call it kludgy and it causes trouble for external ones. it is not very elegant, but I haven't yet heard one report where it didn't work or caused problems for externals. That said, I wouldn't object to a cleaner solution. > 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 don't think we want to force plug-in developers into using glade. > 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. now you've left me and I think you are mixing up several totally independent things here. I can see the relationship between the UI and i18n, but what has the pixel-data API to do with this? And what is stopping you to use the GimpPixelRgn interface? (http://sven.gimp.org/1.2/docs/libgimp/libgimp-gimppixelrgn.html) > - 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. As it stands I don't see how this is supposed to work. Could you outline this a little more detailed, please? > > 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. well, I haven't heard from Ingo during the last ten months, so it will probably never happen unless somebody else tackles it. > > 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. I wanted to say that XML does not give us anything we couldn't have done years ago using for example sexpressions. Of course we can decide to throw away all our parser code and redo the well-working system of gimp rc files just because using XML is what everyone does nowadays. Unless there's a really good reason, we probably shouldn't. Salut, Sven
