On 6 Oct 2001, at 12:37, Daniel Egger wrote: > 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) What is 'the header kludge'? I never got that bit. > and for plugin descriptions because it makes them > more versatile and not bound to the distribution. Plug-ins are a whole different ball game by themselves. There still is no solution for distributing plug-ins apart from the few that will remain in the GIMP core distribution (the plug-in manager thing). Perhaps it is better to discuss plug-in localisation in that context. > > 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. Someone mentioned how well Dia seemed to be doing in that respect. Well, Dia puts the text strings for a sheet in a different file per sheet. Even with only 8 supported languages, this already looks totally cluttered to me. The tips file is 9 kB now. With 15 supported languages (how many on the way?), that would become 135 kB. We'd need a tool to merge changes, or would CVS be enough? You cannot expect translators to wade through 30 lines of other languages to be able to add his/her own translation (30 lines per string to be translated, that is), so that translators do need to work on separate files. > > 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. Hm? I distinctly remember working with SGML-tools way before XML was even invented. It is just a subset of SGML you know, and not that good at it. There is nothing you can do with XML that you cannot do with SGML. XML apps are usually not meant to be read and edited by humans, so I expect you have got a tool for the translators in mind? > 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. gettext is also a standard. XML was developed to give marketdroids a new fad to woo, whereas gettext was developed to let translators do their thing. I know which I as a translator prefer. This is not to say that if you come up with a good XML solution I won't look at it, but I just do not see the merits right now. If we tarred the tips directory, would that solve your 'many files' problem? ;-) -- branko collin collin@xxxxxxxxx
