Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Mon, 2001-10-08 um 22.47 schrieb 1002574041: > I really think we should use XML for the tips but Marc is probably right > that it only makes sense if we use it for other files too. If we decide > to tackle some of our plug-in problems with XML, we will probably want a > real XML parser. That would give us enough good reasons to depend on > libxml2. With a powerful XML library at hand, it will be trivial to solve > the i18n problems that intltool can't handle for us now. ACK, I'm also for the all-in-one solution, let's close this silly thread then and concentrate on work. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Mon, 2001-10-08 um 17.46 schrieb 1002555985: > Which GNOME components does GIMP use? None, that's the point. :) -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > On Mon, Oct 08, 2001 at 06:53:24PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > > As Sven already mentioned, the solution would consist of adding a new > > I would also agree that the header idea is best, HOWEVER, Sven > surprisingly offered that it would be 10 minutes or so to use xml (he > seemed almost eager to do it), so I am undecided on what is the simplest > solution. > > I'd be for the header idea myself, not liking the idea of adding xml > parsing to gimp for just one file. But the idea is when we do that for > one file we might do that for other files (not svens idea), and xml is > certainly broader known to people than the current fileformat. well, I'd still say writing the parser is simple and won't introduce much overhead. However I had to find out today that the tools available for i18n of XML files don't really work for us. intltool does not seem to be able to handle our XML file reasonably well. Perhaps we should go with the header solution for now. We can always change this to XML later if the tools get better (I have filed a bunch of bug-reports for intltool). Since the strings will be translated in po files no matter how we decide, it shouldn't matter from the translators point of view. I really think we should use XML for the tips but Marc is probably right that it only makes sense if we use it for other files too. If we decide to tackle some of our plug-in problems with XML, we will probably want a real XML parser. That would give us enough good reasons to depend on libxml2. With a powerful XML library at hand, it will be trivial to solve the i18n problems that intltool can't handle for us now. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Mon, Oct 08, 2001 at 06:53:24PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > As Sven already mentioned, the solution would consist of adding a new I would also agree that the header idea is best, HOWEVER, Sven surprisingly offered that it would be 10 minutes or so to use xml (he seemed almost eager to do it), so I am undecided on what is the simplest solution. I'd be for the header idea myself, not liking the idea of adding xml parsing to gimp for just one file. But the idea is when we do that for one file we might do that for other files (not svens idea), and xml is certainly broader known to people than the current fileformat. > application. The size of the initialized data will be increased > by 6 KB. and, as I mentioned, you don't usually pay for data you don't access. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Mon, 08 Oct 2001, Sven Neumann wrote: > Daniel could you please take the discussion about UTF-8 and editors > somewhere else?! Then, if you want to propose something that is GIMP > related, please take your time to write up an elaborate proposal and > try to explain your ideas in a way that allows us to discuss them > in a constructive manner?! Last, but not least, please try to respect > others people's work and opinions. Thank you very much. Well, I was about to say something similar. If you want to have a discussion involving a re-organization of the translation of the Gimp, then it would be better to _at least_ change the subject line to something more appropriate. The tips would be affected by the changes that you are proposing, but that would only be a side effect of more important changes. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
For what it's worth, here is my opinion on the Tip of the Day messages
and their translations. In summary: keep it simple! I know that
being the one who introduced these tips in the Gimp does not grant me
any special priviledges (especially since I am not translating them)
but it looks like the easiest option for the translators would be to
put the tips in a .h header file and the translations in .po files.
Although it could appear to be less flexible than using an XML file,
the header file has the advantage that it can be translated in the
exact same way as any other part of the Gimp, without requiring any
special method or special tool. All translators who are able to
translate the code of the Gimp will automatically know what they have
to do in order to translate the tips (this is important for those who
come from the GNOME translation team and may not be very familiar with
the Gimp yet). It will also reduce the size of the code because we do
not use a separate parser and all the gettext stuff is already used by
other parts of the code. (*)
As Sven already mentioned, the solution would consist of adding a new
file gimp_tips.h in the source code, containing something like this:
const gchar *tips[] =
{
N_("This is the first tip."),
N_("This is the second tip and it has bold text."),
N_("This is the last tip. Now, you are on your own.")
};
gint n_tips = G_N_ELEMENTS (tips);
The multi-line tips should be included in one string (with line
breaks) because that will be easier to translate.
This format does not prevent anybody from exporting the tips to an XML
or HTML file and then importing it into another tool. For example, we
could include the following very simple program in the source
distribution of the Gimp:
#include "config.h"
#include
#include "libgimp/gimpintl.h"
#include "gimp_tips.h"
int
main (int argc, char **argv)
{
gint i;
INIT_LOCALE ("gimp");
printf ("\n");
for (i = 0; i < n_tips; i++)
{
printf (" \n%s\n \n", tips[i]);
}
printf ("\n");
}
This very simple program (or a more elaborated version of it) would
allow any translator to output the strings in any format that is
suitable for usage in another environment.
-Raphael
(*) Here, I am talking both about the number of lines of source code
that have to be maintained and the size of the compiled
application. The size of the initialized data will be increased
by 6 KB.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Daniel could you please take the discussion about UTF-8 and editors somewhere else?! Then, if you want to propose something that is GIMP related, please take your time to write up an elaborate proposal and try to explain your ideas in a way that allows us to discuss them in a constructive manner?! Last, but not least, please try to respect others people's work and opinions. Thank you very much. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Mon, 2001-10-08 um 03.53 schrieb 1002506022: > > gettext and po > > files are a dead end for modular applications because they only behave > > well for monolithic and small applications; both of which GIMP > > definitely isn't and for sure even less will be in the future. > Evolution certainly isn't monolithic nor small, and yet it has scaled > well to almost 3000 messages as of today. Yes, and the point is? Evolution is using XML and xml-i18n-tools, but it has the slight "advantage" over GIMP that it's heavily relying on GNOME components for remote activation and components. Though I'm using it it's a huge bloaty, slow and buggy piece of software and it's for sure not a good example for the way we should go with GIMP in the future. > I sure agree with you here, but I'm fairly confident in that there will > never any "ditching" until said alternative tools are a reality and > tested in practice, and have extensive support. We're talking about the development branch here. It's discouraged to touch the translations at the moment and thus we have a lot of time until the translator tools would have to be available, so no need to worry now that there would be no "easy" way to work translations tomorrow. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Mon, 2001-10-08 um 03.39 schrieb 1002505193: > > You don't have to, that's the trick. > Ok, I got the impression from your message that this was the case. The trick about it is that there's nothing special, so you can use any editor you like, like with ascii files just the XML represents information structured. > > Easy, you tell it. > So this is an extra step that I have to do whenever editing a > translation with your scheme? Give it a default and change it whenever you do something differently. > > Black magic but easy to hack. > I'd like to see that hack first. I'm no emacs crack but it should be quite easy to realise there. For vim it's just a matter of minutes. > No, I'm using Emacs pure and simple. And by the reasoning in your > previous mail, you implied that it's an inferior tool, just because it > doesn't natively support UTF-8 yet. No, I assumed that emacs would support UTF-8 natively which seems was sort of a naive conclusion by the fact that many people use it even for webbrowsing and mailreading. It's certainly a very mighty editor though I don't use it. > Native support for UTF-8 is uncommon and of course that is bad and > should get better, but that doesn't change the fact that forcing > translators to use UTF-8 today causes real and practical problems for > translators. Consider tools that don't support UTF-8 buggy. And most certainly those will be fixed sooner or later. As stated in one of my previous mails emacs supports UTF-8 by installing an additional package so this is not much of a problem. > Editors aside, simply looking at and otherwise using console text tools > on UTF-8 files with non-ASCII content, usually has little if any > support. Time for a reality check. Back at SuSE we had a special UTF-8 taskforce and most of the developpers where quite surprised by the unveiled by the results of their survey; quite a lot of the recent applications are at least partly able to cope with UTF-8. There's no need to think backwards when trying to plan for the future. > We are not talking about some change that will give new functionality. > We are talking about a proposed forced change that for all intents and > purposes will give no benefit to translators (although you like to label > them as such) but rather the opposite - instead of helping translators > you want to make what they do more difficult, as has been already > extensively discussed in this thread, with questionable gains at best. No, I have no intend to make anything more difficult. > > Heh, I you think work is lost then you're probably underestimating us, > > of course someone will hack up a script to convert from the old to > > the new style. > That still won't solve the problems: > 1) Your proposed solution still doesn't have the functionality > of gettext as you described it, It does. > 2) Your proposed solution still doesn't solve the one-file > problems, It also does. > 3) Your proposed solution still doesn't solve the problems of > no other tools supporting this format, including translation > memories and statistics tools, Tools are very easy to write, just mention your wish. > 4) Your proposed solution still remains vaporware for the time > being. No, it has been used in DIA. > It's not the matter of a "simple script", and I sure hope that you do > not still beleive so. I do. > You're certainly right about fear. Fear about a single person claiming > that he can in no time replace software that has been evolved for > decades, and that he intends to do so and enforce this change, all while > this person openly admits that the proposed "solution" won't have hardly > any of the essential features of the system to be replaced, and admits > that he does hardly do any translation work at all, or understand why > the features are necessary. This is FUD, sorry. > Sure, and we can do this already today by using the combination of XML > and intltool. It's okay, I got your point and we will go with the intltool solution for now to please an apeace all the translators out there. > I fail to see how Q_() will make software buggier (on the contrary I'd > say), and I'm sure the persons responsible would like more constructive > criticism and suggestions than "it's bullshit". Gettext in general, though widely used, is bullshit; and a hack to cover that fact won't make it better. Even if you add a hash like "REW342rfwe!Some Text" to your strings to make it context aware you haven't solved the problem but just worked around it in an evil way, not to mention that this certainly doesn't ease the translators work you're so eager to mention. > Please explain (we can do that in private or preferrably on gnome-i18n > since that surely will become off-topic), because although I'm highly > sceptical to this as a solution for any forseeable future, I'm curious > to what you have in mind. Consider having a "master catalog", this one contains the basic
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
"pcg"@goof.com ( Marc) (A.) (Lehmann ) wrote: > > My mailer doesn't (pine) > > pine doesn't even parse rfc822 addresses (like mine) - let's face it, pine > is the worst mailer around with regards to features, standards compliance > etc. Everybody is free to use it, but citing pine as an example of a > modern, average program that doesn't support utf-8 is just unrealistic ;) Heh, I'm bound to agree. pine hasn't even supported iso-8859-1 by default for that long, a long time it was configured just for ascii by default. > (As a matter of fact, most people use netscape, outlook etc.. which > work fine, probably kmailxxxtool does as well. All these programs are > maintained and at least try to comply with standards). I'm not sure about Netscape though. > > my editor doesn't (Emacs) > > It can be taught to. Yes, there are two bad hacks for enabling *some* UTF-8 support in Emacs, but I think you're forgetting that this was about native support? > I worked with vim-5.6 and utf-8 for a long time, and > vim does have no native support. Actually wim 6.0 is said to have native UTF-8 support, but that doesn't change a thing for those who dont use vi/vim. :-( > > my terminal doesn't (gnome-terminal) > > it still doesn't need to support utf-8 to display unicode - at least > the subset you are interested in. gtk will soon support utf-8 (put > differently: the next release will). I know about that, thank you, but full native UTF-8 support in gnome-terminals terminal widget still needs to implemented even when gtk+ 2.0 is released. > > my irc client doesn't (xchat), and lots of ordinary console text tools > > don't. > > I have no idea what console text tools are meant to be. Most text-utils > trivially support utf-8 (they basically don't care, and modern systems > often offer a utf-8 locale (glibc does), which makes lots of x programs > and text utils act wonderfully! (i can even enter utf-8 in rxvt ;)). I've experienced problems with multibyte characters in the past at least with tools like less. Also, no sane UTF-8 fonts seem to be supplied by default, so even if the tool doesn't care, it requires trickery to get correct output. > I think the main problm is that people aren't aware of all this. I think the main problem is that it requires a lot of tweaking to get even some UTF-8 support for a lot of applications, if they even claim to support it. > > > utf-8 support is more common than supprot for most other charsets, > > > actually. > > > > Hardly compared to iso-8859-1, which I was referring to. > > Again, by far the majority of languages cnanot be represented in > iso-8859-1. Heck, even most of europa can't, strictly speaking. What has this to do with it? You claimed that UTF-8 support was more common than support for most other charsets, and I pointed out that this was hardly true for iso-8859-1. > > No it's not. Tell me any console text tool that *doesn't* handle > > iso-8859-1 correctly by default nowadays. > > I still don't know, but neither bash nor epic nor ircii do that until > configured to do so. Bash is configured to support iso-8859-1 by default, since even LC_CTYPE="en_US" specifies iso-8859-1. When it comes to ircii, I have to admit that you are right, but if you could insist that I shouldn't use pine because it sucks, I could say the same about ircii. > And pinning down on iso-8859-1 is, again, neglecting most of the world. How very true, but you're forgetting what you claimed earlier. You claimed that UTF-8 support was more common than support for other character sets. I'm simply pointing out that you seem to be wrong in that aspect. > > > Hint: you cannot represrnt the majority of languages with ascii. > > I'm very well aware of that fact, thank you. > > I don't think so ;) Why? > > I know that, but if I'm understanding it correctly, you are suggesting > > that iconv be used manually before and after every translation update as > > extra steps? > > Are you suggesting that the holy emacs is incapable of such a primitive > thing itself? Yes it is, unfortunately. > gnus already converts utf-8 to local charsets (and back) > fine. and utf-8 support is high priority I would think. It seems to have been a high priority for quite some time then. The Emacs page still mentions "We are now working on Unicode support" just like it did almost a year ago when I last checked. This is my point, things are moving slow when it comes to UTF-8 support in tools, and for many western European locales forcing use of UTF-8 will actually be a step backwards in terms of support, and a pain to use, and actually slowing down other localization work for these locales. That is why I advocate that UTF-8 should be converted automatically when needed, and not forced down the throat of people that need working tools for the time being. > > Manual steps that are completely unnecessary since intltool > > does this automatically. > > If your editor forces you to do that manually you should e
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Mon, Oct 08, 2001 at 05:00:27AM +0200, Christian Rose <[EMAIL PROTECTED]> wrote: > My mailer doesn't (pine) pine doesn't even parse rfc822 addresses (like mine) - let's face it, pine is the worst mailer around with regards to features, standards compliance etc. Everybody is free to use it, but citing pine as an example of a modern, average program that doesn't support utf-8 is just unrealistic ;) (As a matter of fact, most people use netscape, outlook etc.. which work fine, probably kmailxxxtool does as well. All these programs are maintained and at least try to comply with standards). > my editor doesn't (Emacs) It can be taught to. I worked with vim-5.6 and utf-8 for a long time, and vim does have no native support. > my terminal doesn't (gnome-terminal) it still doesn't need to support utf-8 to display unicode - at least the subset you are interested in. gtk will soon support utf-8 (put differently: the next release will). > my irc client doesn't (xchat), and lots of ordinary console text tools > don't. I have no idea what console text tools are meant to be. Most text-utils trivially support utf-8 (they basically don't care, and modern systems often offer a utf-8 locale (glibc does), which makes lots of x programs and text utils act wonderfully! (i can even enter utf-8 in rxvt ;)). I think the main problm is that people aren't aware of all this. > > utf-8 support is more common than supprot for most other charsets, > > actually. > > Hardly compared to iso-8859-1, which I was referring to. Again, by far the majority of languages cnanot be represented in iso-8859-1. Heck, even most of europa can't, strictly speaking. > No it's not. Tell me any console text tool that *doesn't* handle > iso-8859-1 correctly by default nowadays. I still don't know, but neither bash nor epic nor ircii do that until configured to do so. And pinning down on iso-8859-1 is, again, neglecting most of the world. > > Hint: you cannot represrnt the majority of languages with ascii. > I'm very well aware of that fact, thank you. I don't think so ;) > I know that, but if I'm understanding it correctly, you are suggesting > that iconv be used manually before and after every translation update as > extra steps? Are you suggesting that the holy emacs is incapable of such a primitive thing itself? gnus already converts utf-8 to local charsets (and back) fine. and utf-8 support is high priority I would think. > Manual steps that are completely unnecessary since intltool > does this automatically. If your editor forces you to do that manually you should exchange it for something that works. But anyways, yes, the single-file-idea is a bad one. > > > I'm sure you'll find out many other surprises when you check what text > > > tools in any major GNU/Linux distribution actually fully supports UTF-8, > > I'd say the majority does. > In my experience, that's far from true. I use them every day - are you sure you really tried? > Nevertheless, insulting me doesn't make your opinion more valid. Nobody is insulting you. But if you think so, I will try to be more careful in the future. > Why would this manually piping be favorable over using intltool that > already does this automatically, requires no additional manual steps in I don't know - I didn't offer an answre to this question. It would certainly make it possible to use utf-8 as the main format for files, though. > I'm a translator for a non-ascii language, Make it non-latin1 then. Most of europe has a slight compatibility problem now, since iso-8859-15 will be very common very soon now. > And so we do in fact agree... On these points: certainly ;) And even without any insult, believe me! -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: > > Yes, but that's the very nature of the ChangeLog. It is *supposed* to be > > edited with every commit. > > Why does that make a difference? > Rather the fact that every entry has to be added at the top of the file > to keep the chronological order makes it much more conflict prone then > any other file. Sure, but conflicts in ChangeLogs are easy to spot (since changes go at the top) and almost always easy to spot. Furthermore, you completely missed the point in that I wasn't talking about conflicts, but about the dangers of changes other people do to my translation and the change going completely undetected due to the heavy commit traffic a single translation file would have, and the chance of detecting those changes going from close to 1 with po files to close to 0 with a single edited translation file, without having to spend hours of extra work investigating changes to see which ones are appropriate and which ones are not (the ones affecting my translations that I didn't know about). > > Also, ChangeLogs are mostly for developers. Not many people don't cry or > > flame if there is a typo or a tab or dot is missing. However, if > > something is wrong in a translation, which usually is immediately > > visible to a large number of end users, that's another matter. > > Hah, you've never seen me getting mad when syngin or bex messed up the > structure of gimp-help's ChangeLog :) I have also cleaned up some ChangeLogs in the past with respect to tabs, spaces and 80-character line width, but this remains to be only cosmetical changes. A change in a translation can easily be more devastating and visible than so. > > But in that case I can at least easily spot it! I thought I had already > > explained that it is the easy and early detection of other people's > > grateful unannounced changes to my translations I want to keep. Why do > > you think I use an $Id$ tag in all my po files? > > Dunno, because you want to piss of other people? Please explain why you assume maintainership and keeping track of commits automatically makes a person wanting to "piss off" other people. > > Surely, but the problem is worse with translations. If you accidentally > > remove a line too much in the source, chances are big that you will > > notice that when compiling to test your changes. > > If other people edit a .desktop or XML file directly and accidentally > > cut away the line with my translation, it will not get detected > > syntactically (that languages' translation is simply gone and it is > > still valid syntactically), the only one developer noticing that it is > > missing will be me and I will have little chance of detecting it myself > > until I revisit the translation and carefully inspect it manually. > > Missing lines are probably much easier to detect then misspelled ones. Yep. I couldn't have said it better myself. Lingustic changes are far worse, and also almost impossible to detect in such a file without actually verifying the translation. > > Someone else doing a cvs diff for that commit could also notice the > > change by accident, but he or she might not know that this was was an > > unwanted change, and the chances of he or she notifying me, or knowing > > that I should be notified, are probably even smaller. > > You're carying to much about theoretical problems. They are not theoretical, no matter how much I wish they were. I've experienced this again and again with .desktop files in CVS before we started to use intltool. A typical scenario: 1) Translator A,B,C,D,E adds their translations to the file 2) Translator F does the same, but accidentally saves and commits the file in his native encoding, effectively ruining many existing translations 3) Translators G,H,I,J add their translations to the file 4) Translator B revisits the file and finds out that his translation is broken, and has to dig in cvs history to find out why 5) After "why" the next step is to ask all translators to verify that their respective translation is still correct and that they make any necessary changes. It's not a matter of a simple revert since other changes have been added in the mean time 6) Translators A,B,C,D,E,F,G,H,I,J verify their translations And repeat the process, until the same mistake happens again... This is a highly prominent problem of "all translation in the same file" schemes, and it is by no means new or theoretical only, these are cold hard experience from these things happening in cvs in reality. > We've have been there > before at university: 40 people hacking on XML files together. After > some days of chaos I gave an CVS crashcourse and after that we had no > problems at all, that were several hundreds XML files consisting of > a few thousand lines each. I think this is hardly comparable to translations. Translations are completely separetely main
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
"pcg"@goof.com ( Marc) (A.) (Lehmann ) wrote: > > Native support for UTF-8 is uncommon and of course that is bad and > > Sorry? my mailer supports it (mutt) my editor supports it (vim), my terminal > supports it (xterm), my irc-client supports it (epic), my browser(s) suipport > it (lynx, netscape, mozilla), my os supports it on the console (linux)... My mailer doesn't (pine), my editor doesn't (Emacs), my terminal doesn't (gnome-terminal), my irc client doesn't (xchat), and lots of ordinary console text tools don't. > utf-8 support is more common than supprot for most other charsets, > actually. Hardly compared to iso-8859-1, which I was referring to. > > Editors aside, simply looking at and otherwise using console text tools > > on UTF-8 files with non-ASCII content, usually has little if any > > support. > > The same is true for anythign except ascii. No it's not. Tell me any console text tool that *doesn't* handle iso-8859-1 correctly by default nowadays. > Hint: you cannot represrnt the majority of languages with ascii. I'm very well aware of that fact, thank you. > (and I was told emacs can do utf-8. at least people found a way to decode > my mails properly in emacs). Maybe it's just that emacs can't natively > edit utf-8 text No, it cannot do it natively > but it should be possible to just convert it to some > native charset. every unix comes with iconv I know that, but if I'm understanding it correctly, you are suggesting that iconv be used manually before and after every translation update as extra steps? Manual steps that are completely unnecessary since intltool does this automatically. > > I'm sure you'll find out many other surprises when you check what text > > tools in any major GNU/Linux distribution actually fully supports UTF-8, > > I'd say the majority does. In my experience, that's far from true. > > Sure the tools need to get updated in the end, but it's a very slow > > process that has already taken years with little happening and surely > > many years remain to come > > I realyl think you need a reality check. Thank you, I have checked reality regarding UTF-8 support every time this has been brought up (and as a translator, I've experienced this debate a lot of times), and every time the disappointing results have been that progress is slow and that many of even the most common applications don't have support, or in some cases where UTF-8 support is claimed it is incomplete or broken. Nevertheless, insulting me doesn't make your opinion more valid. > > have to use UTF-8 is a big practical problem for translators. Note that > > s/big/little/ every editor should eb able to pipe through some > external program (iconv -f utf-8 -t koi8-r for russian for example) on > loading/saving. Why would this manually piping be favorable over using intltool that already does this automatically, requires no additional manual steps in the process of translation, and lets translators work with their preferred encoding? > And I am quite sure translators for non-ascii languages > already know how to cope with charset problems - they needed to. I'm a translator for a non-ascii language, but I never have to cope with charset problems (aside from the thankfully very rare occasions when people demand things to be in UTF-8). So I guess this effectively makes this theory moot. > > That still won't solve the problems: > > (agreed to all of them - i wa spurely concerned about utf-8 ;) > > > > While I do agree with Marc that XML is not the all-purpose solution I > > > really think it's going to help in the case of localisation by the > > > consistent use of UTF-8 and other concepts like includeable files and > > > overrideable tags. > > XML and UTF-8 are two completely orthogonal concepts - xml is represented > in unicode and can be written in almost any encoding (ascii, viscii, > whatever). > > I don't see any problem having multiple different(!) files with different > encodings, pleasing whatever a local translator likes. And so we do in fact agree... Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Mon, Oct 08, 2001 at 03:39:53AM +0200, Christian Rose <[EMAIL PROTECTED]> wrote: > Native support for UTF-8 is uncommon and of course that is bad and Sorry? my mailer supports it (mutt) my editor supports it (vim), my terminal supports it (xterm), my irc-client supports it (epic), my browser(s) suipport it (lynx, netscape, mozilla), my os supports it on the console (linux)... utf-8 support is more common than supprot for most other charsets, actually. > Editors aside, simply looking at and otherwise using console text tools > on UTF-8 files with non-ASCII content, usually has little if any > support. The same is true for anythign except ascii. Hint: you cannot represrnt the majority of languages with ascii. (and I was told emacs can do utf-8. at least people found a way to decode my mails properly in emacs). Maybe it's just that emacs can't natively edit utf-8 text, but it should be possible to just convert it to some native charset. every unix comes with iconv, and most do support utf-8 for example. > I'm sure you'll find out many other surprises when you check what text > tools in any major GNU/Linux distribution actually fully supports UTF-8, I'd say the majority does. > Sure the tools need to get updated in the end, but it's a very slow > process that has already taken years with little happening and surely > many years remain to come I realyl think you need a reality check. > have to use UTF-8 is a big practical problem for translators. Note that s/big/little/ every editor should eb able to pipe through some external program (iconv -f utf-8 -t koi8-r for russian for example) on loading/saving. And I am quite sure translators for non-ascii languages already know how to cope with charset problems - they needed to. > That still won't solve the problems: (agreed to all of them - i wa spurely concerned about utf-8 ;) > > While I do agree with Marc that XML is not the all-purpose solution I > > really think it's going to help in the case of localisation by the > > consistent use of UTF-8 and other concepts like includeable files and > > overrideable tags. XML and UTF-8 are two completely orthogonal concepts - xml is represented in unicode and can be written in almost any encoding (ascii, viscii, whatever). I don't see any problem having multiple different(!) files with different encodings, pleasing whatever a local translator likes. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: > > I think you need to > > consider the experience that menthos has with this situation. If we > > consider what we might end up with in the future (many more tips, more > > complicated tips, more languages), it makes sense to plan po right now. > > I'm never planning for now but always for the future. I think we have the problem right here. Although future concept "if we did this from scratch" ideas are always interesting, they are hardly ever a solution to the situation today, simply because they are by definition not implemented, and often hardly have any compability with the existing software. So I think you should devote your resources to implement this software, rather than trying to enforce the use of the not-written-yet software today. It sure sounds backwards to me. > gettext and po > files are a dead end for modular applications because they only behave > well for monolithic and small applications; both of which GIMP > definitely isn't and for sure even less will be in the future. Evolution certainly isn't monolithic nor small, and yet it has scaled well to almost 3000 messages as of today. > I like the idea of the XML tip-files with the xml-i18n-tools which will > transform between XML and .po for now because it's a good idea for the > future and as soon as the translators see the deficiencies of .po > and/or new good tools for XML files we can easily ditch them and > go for the right thing(TM). I sure agree with you here, but I'm fairly confident in that there will never any "ditching" until said alternative tools are a reality and tested in practice, and have extensive support. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: > > Why should I have to use a special XML editor? > > You don't have to, that's the trick. Ok, I got the impression from your message that this was the case. > > How does the editor know what language I want to edit, > > Easy, you tell it. So this is an extra step that I have to do whenever editing a translation with your scheme? > > and how does it automatically filter away > > everything else except the original string and my language? > > Black magic but easy to hack. I'd like to see that hack first. > > Do you believe everyone uses VIM or has the desire to be forced to do so? > > No, but having the right tools will always have a big impact on the > efficiency of your work. Nothing to argue about that. > I really don't want to know that you're using > to edit textfiles but if you're not skilled with one of the major > ones (No, MicroSoft Notepad and Wordpad are not major) then you're most > likely wasting your time. No, I'm using Emacs pure and simple. And by the reasoning in your previous mail, you implied that it's an inferior tool, just because it doesn't natively support UTF-8 yet. I can tell you that this is not true, it certainly is a capable editor, and it shares the state of many other popular and common editors. Native support for UTF-8 is uncommon and of course that is bad and should get better, but that doesn't change the fact that forcing translators to use UTF-8 today causes real and practical problems for translators. Editors aside, simply looking at and otherwise using console text tools on UTF-8 files with non-ASCII content, usually has little if any support. > > Surely all translators are bound to agree with you. All incompatible > > 8bit encodings are a nightmare, and UTF-8 is the future. But that > > doesn't change the fact that we live with the tools we have today. We > > cannot stop translating or reduce the pace of translations until we live > > in a UTF-8 clean world, because simply there may never be such a world, > > and it is out of our control as translators, and for most idividual > > developers too, I'd imagine. It will be a long conversion process, and > > we have to support multiple encodings during that time. We can already > > store translations in UTF-8 today, but editing them is another matter. > > This is free and open software, no one is used to walk the hard way just > because there are only a few tools available; pick one of the available > tools or improve others instead of living in pain. We are not talking about some change that will give new functionality. We are talking about a proposed forced change that for all intents and purposes will give no benefit to translators (although you like to label them as such) but rather the opposite - instead of helping translators you want to make what they do more difficult, as has been already extensively discussed in this thread, with questionable gains at best. Note that I'm not at all against the use of XML, on the contrary if it helps developers or is more extensible or has any other development benefit I'm all for it. I'm against the forcing of translators to use this format for editing (as per your proposal) instead of using intltool as middle layer and letting translators use their tools. I'm not a developer and I rather devote my time on translating than on hacking code. Thus I have no interest in devoting time to make your proposed system usable by translators and reinvent the wheel, rather than using what's already available and working (intltool). > > Also, the encoding problem remains to be only one of the problems with > > your solution. > > Now we're getting closer to the point I hope. > > > So you're saying that Emacs and many other editors are bad? Please don't > > turn this into an editor war. > > Emacs can't do UTF-8? No it can't. It's a planned feature, but it has remained so for a long time, at least as long as I have kept checking out the roadmap and feature announcements. > (minutes later) Hm, okay I imagined a major editor like emacs would > support UTF-8 natively but I was proven wrong. I'm sure you'll find out many other surprises when you check what text tools in any major GNU/Linux distribution actually fully supports UTF-8, and how many of the common ones you have to leave aside. This is the problem I'm talking about. > Though there is a package here > ftp://ftp.cs.ust.hk/pub/ipe/oc-unicode-0.72.2.tar.gz I have previously tried to use both of these hacks (there are two ones) but with little success. Also, they appearantly have problems of their own. If I remember correctly, at least one of them only supported viewing of UTF-8 and not editing. If they had been acceptable I'm sure they would have already been incorporated into the main Emacs distribution long ago... :-( > that adds the missing support to version 20.4 (20.6 preferred). > Actually I really don't care what people are using and I'm not saying > any editor is worse or better th
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 20.16 schrieb 1002478606: > Yes, but that's the very nature of the ChangeLog. It is *supposed* to be > edited with every commit. Why does that make a difference? Rather the fact that every entry has to be added at the top of the file to keep the chronological order makes it much more conflict prone then any other file. > Also, ChangeLogs are mostly for developers. Not many people don't cry or > flame if there is a typo or a tab or dot is missing. However, if > something is wrong in a translation, which usually is immediately > visible to a large number of end users, that's another matter. Hah, you've never seen me getting mad when syngin or bex messed up the structure of gimp-help's ChangeLog :) > But in that case I can at least easily spot it! I thought I had already > explained that it is the easy and early detection of other people's > grateful unannounced changes to my translations I want to keep. Why do > you think I use an $Id$ tag in all my po files? Dunno, because you want to piss of other people? > Surely, but the problem is worse with translations. If you accidentally > remove a line too much in the source, chances are big that you will > notice that when compiling to test your changes. > If other people edit a .desktop or XML file directly and accidentally > cut away the line with my translation, it will not get detected > syntactically (that languages' translation is simply gone and it is > still valid syntactically), the only one developer noticing that it is > missing will be me and I will have little chance of detecting it myself > until I revisit the translation and carefully inspect it manually. Missing lines are probably much easier to detect then misspelled ones. > Someone else doing a cvs diff for that commit could also notice the > change by accident, but he or she might not know that this was was an > unwanted change, and the chances of he or she notifying me, or knowing > that I should be notified, are probably even smaller. You're carying to much about theoretical problems. We've have been there before at university: 40 people hacking on XML files together. After some days of chaos I gave an CVS crashcourse and after that we had no problems at all, that were several hundreds XML files consisting of a few thousand lines each. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 19.34 schrieb 1002476057: > Prof: Seriously here... are you a translator? It's not my job. Though you can imagine that I have some experience in this area as I'm the one who introduced localisation to the GIMP and wrote a big part of the first translation for it. I did this several times with other applications as well so I know both the problems of the implementation and the translationside. Should I mention that not even the tools worked properly back then and fuzzy translation was just a dream? > I think you need to > consider the experience that menthos has with this situation. If we > consider what we might end up with in the future (many more tips, more > complicated tips, more languages), it makes sense to plan po right now. I'm never planning for now but always for the future. gettext and po files are a dead end for modular applications because they only behave well for monolithic and small applications; both of which GIMP definitely isn't and for sure even less will be in the future. I like the idea of the XML tip-files with the xml-i18n-tools which will transform between XML and .po for now because it's a good idea for the future and as soon as the translators see the deficiencies of .po and/or new good tools for XML files we can easily ditch them and go for the right thing(TM). -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 18.43 schrieb 1002473012: > Then you should take a new look. It certainly does today. Fine with me. > Why should I have to use a special XML editor? You don't have to, that's the trick. > How does the editor know what language I want to edit, Easy, you tell it. > and how does it automatically filter away > everything else except the original string and my language? Black magic but easy to hack. > Do you believe everyone uses VIM or has the desire to be forced to do so? No, but having the right tools will always have a big impact on the efficiency of your work. I really don't want to know that you're using to edit textfiles but if you're not skilled with one of the major ones (No, MicroSoft Notepad and Wordpad are not major) then you're most likely wasting your time. > Surely all translators are bound to agree with you. All incompatible > 8bit encodings are a nightmare, and UTF-8 is the future. But that > doesn't change the fact that we live with the tools we have today. We > cannot stop translating or reduce the pace of translations until we live > in a UTF-8 clean world, because simply there may never be such a world, > and it is out of our control as translators, and for most idividual > developers too, I'd imagine. It will be a long conversion process, and > we have to support multiple encodings during that time. We can already > store translations in UTF-8 today, but editing them is another matter. This is free and open software, no one is used to walk the hard way just because there are only a few tools available; pick one of the available tools or improve others instead of living in pain. > Also, the encoding problem remains to be only one of the problems with > your solution. Now we're getting closer to the point I hope. > So you're saying that Emacs and many other editors are bad? Please don't > turn this into an editor war. Emacs can't do UTF-8? (minutes later) Hm, okay I imagined a major editor like emacs would support UTF-8 natively but I was proven wrong. Though there is a package here ftp://ftp.cs.ust.hk/pub/ipe/oc-unicode-0.72.2.tar.gz that adds the missing support to version 20.4 (20.6 preferred). Actually I really don't care what people are using and I'm not saying any editor is worse or better than any other (well, the most obvious ones excluded). > Escaping isn't realistic at all. I suspect your experience with having > to write large amounts of text in your native language and escaping all > non-ASCII characters is limited. I have to do that all the time, Umlauts in LaTeX are preferrable escaped by an ", and in HTML or DocBook I also have to use the escaped versions, so what's the matter? > It plain sucks for more ways than is possible to count. Welcome to reality, sucks eh? > Escaping everything reduces typing speed (and makes > your fingers hurt), Well, some editors can do it for you but then there're people who prefer american keyboard layout and thus have no choice. > makes it hard to read, introduces a greater danger > of errors (by forgetting to escape, or incomplete escaping) or wrong > escaping (one different escape sequence is similar to all others, while > the result may be entirely different. In other words, a pain to verify > without unescaping). Again, this is something you shouldn't have to care about; the ridicoluous speed increases of computerearchitectures also have their good sides. > > See above. Try the folding feature of vim 6.0, it's really cool. > I don't use vi or vim, and do not plan doing so for the forseeable > future. I believe this is one of the features vim has copied from emacs, so if you're a fan of this brew you should be happy as well. > That's the problem. You are only prepared to replace some limited > gettext functionality, ignoring the rest. Okay, I'm waiting for the promised next mail. :) > They are not. How much do you translate a day? Much of what you base Almost nothing at the moment because most of the interesting software is already translated and I'm far too busy to care about features I don't use myself. > because of the tools. Translation memories and fuzzy matching are most > important parts of this. Fuzzy matches often lead to wrong translations unfortunately. And one of the major problems with the catalogs of big applications is that one cannot easily translate a phrase differently in differing contexts. > I hardly would consider any change of this pace to the worse, because > some developer decided that his homebrewn (but for all practical > purposes inferior) and incompatible translation scheme should be used, > for any progress. And this is what I'm afraid of. Heh, I you think work is lost then you're probably underestimating us, of course someone will hack up a script to convert from the old to the new style. Just the handling in the future would differ and as I already said it's more the fear of a change then a real deterioriation that would be seen here. Moving to a be
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 18.29 schrieb 1002472199: > > Yes, but not very versatile... > Why? It contains the tips and a minimum amoutn of clutter. If you equate > evrsatile == xml because everybody claims to support it I disagree > completely. No, but unlike compiled catalog files xml files can be changed in many ways with any tools and even at runtime and remotely. This makes it very versatile. > Yeah, but a) nobody does that (right)? Changing tips at runtime is maybe not the killerapplication, but it could be quite handy for other purposes. > > The problem with SGML is that it's too complex to grok completely and > > that's why a large amount of people simply ignored it; XML is a subset > That's a story I never heard of before. The reson SGML was not used is > because it was very powerful and complex to implement. That's also very true. > For humans it is easy to grok. > You are comparing sgml with xml-applications. I could just > claim that most sgml-applications are much easier to grok for humans than > xml namespaces or schemas. The problem with SGML is that for every purpose there's a different approach, you'll never stay within SGML but always have to learn DSSSL or other ideas to make it useful. With XML it's different - everything you want to do is within XML, you can validate it with XML (schemas) or transform it with XML (XSL) and that makes a huge difference. It would be rougly comparable if you could programm nice programs in C but would have to learn scheme to execute them and python to identify the results in the printed garbage on the console. > this doesn't sound too encouraging, no? yes, it was a goal to keep xml > "human", but this is a minor goal, others (ease-of-use for machines!) were > more important. Yes, but I really like and appreciate the fact that it is very human-readable and that's why I mentioned it. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote:
> > Whatever the solution regarding GIMP tips turns out to be, translators
> > want to be able to translate them from within po files. I hope everyone
> > has agreed on that :)
>
> not really.
Okay, but that really makes you an exception among translators. This
discussion isn't new, it has been repeated for ages and happens every
time a developer does not understand why po format should be used, but
rather wants his own "brilliant" hack to reinvent the wheel, without
understanding why po format is essential to the majority of translators.
The short answer is "the tools". gettext is industry standard, and there
are a huge amount of tools for creating, maintaining and reusing
translations in this format. Also the few tools included in GNU gettext
itself has many important features.
As far as I know, no translator has ever objected to the need of po
format for these reasons, and we have discussed this extensively. The
problem of people inventing more and more different formats to keep
their software messages in (.oaf, .sheet, various xml formats, .desktop,
.soundlist, .directory, etc etc) in GNOME was a major pain to
translators, and that eventually resulted in the development of
xml-i18n-tools as a middle layer, allowing developers to use their
formats (with those advantages that gives) while on the same time
allowing translators to use their format (with those advantages that it
gives).
Currently it's used for the majority of GNOME modules and the plan is to
use it for all of them. There's no disagreement about that, not that I
know of at least.
> > If you go for XML, I'd recommend using intltool. It's a set of tools
> > designed exactly for this purpose. Since gettext itself doesn't have a
> > clue about XML, intltool works as a middle layer that extracts strings
> > marked for translation in the XML and adds them to header files, so that
> > xgettext can extract them and put them in a pot. The reverse process is
> > usually done at build time, and all the translations merged back into
> > the original XML file.
>
> > You can find intltool in the xml-i18n-tools module in CVS.
>
> Okay, so why would one want this heavy conversion action? If the only
> purpose is to have only one editable catalog instead of several files
> and people really need that then okay...
I have already mentioned the disadvantages of a single translation file
in my previous mail, but there are many more advantages to po format
than that.
Basically it amounts to the fact that there's much more to translation
than just creating a translation. In many cases, creating the initial
translation is the easiest part time-wise: maintaining the translation
as the software evolves (often for many years) and updating and adding
translations of individual messages as they get added to the source over
time, usually takes more effort over a much longer period of time.
This is the single largest weakness of your proposal, it doesn't mention
anything of how this is to be solved, while gettext already has features
for this.
For the initial creation of a translation, the technology with using a
translation memory is becoming more common. This is a single large
collection of all existing translations in po format, that are re-used
for the new translation by running a special tool. My memory is
currently more than 6 MB of text, and gives up to 25% - 30% (depending
on the pot file) of exact matches in a new translation. That means 25%
to 30% less work for me when creating the translation, which usually
amounts to many hours of saved work. Also, even if the number of exact
matches are smaller, the number of close matches ("fuzzy" matches) are
usually large, and these close matches usually save much time when
translating (I don't have to do a complete translation of this message
from scratch but usually only have to make smaller adjustments) and also
helps improving consistency in translations, so that they use the same
translations of identical terminology and writing.
Translation memories can also be used for maintaining translations - as
new messages are added, you can re-run the translation against the
translation memory and match them against existing translations this
way. I myself don't use them this way but solely for new translations,
but I know other people that also use them this way.
Nevertheless, these translation memory tools use the po format since
this is what is used across free software translations, and if you have
decided upon another format, you have to deal with making existing
translation memory tools usable with it. Anything else is a step
backwards.
However, that was only the problems of the cration of translations,
while I previously mentioned that maintaining is the main work. Among
other things, the gettext tools themselves help with the following
issues related to updating translations:
* Fuzzymarking of changed messages. This is a really important feature.
If and when an original message is ch
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: > > Also, one important drawback of keeping all translations in one file in > > CVS, and forcing translators to edit this file, is that it gets almost > > impossible to verify the integrity of translations. As a translator and > > creator and maintainer of the translation, I feel that it is important > > that errors in my translation are my errors alone, and that I'm the only > > one responsible for them. Translation errors introduced by other people > > without permission are, well, "annoying" to say the least. > > It's quite tricky to introduce any errors in XML files and easy at the > same time to fix them. I think you misunderstood what I meant. I wasn't referring to syntactical errors, I was referring to pure language errors. There's no tool in the world other than manual inspection that can help me fully verify those, and I'd rather have to do this tedious work as rarely as possible, as opposed to at every cvs commit of another translator, just to catch an unwanted change of my translation. > CVS guarantees a certain amount of integrity > so having conflicting changes is not a problem. How does this solve the "I committed a newer file with my translation updated, but accidentally/intentionally messed with yours" problem? I don't see how. > AND: XML can be easily > verified to be correct when there's a schema file, even remotely, and > in theory the GNOME CVS server could be teached to only allow checkin > of valid XML files. Yes, you can check syntax, but you completely missed my point. > > With a whole bunch of different people committing to the same file, > > verifying the integrity of individual translations becomes almost > > impossible. > > It's not more of a problem then with several people working on > other files concurrently; that's what CVS is for. It's different. First of all, for every source file it is only a small number of trusted people that should be able to commit, namely the developers of that project. I think there are not many projects where more than 20 developers are expected to commit directly to the same source file. You're free to correct me if I'm wrong. But in the GTP we have 40 language teams alone, most of them with at least one person with GIMP cvs access. Even if we only make the assumption "one language team = one translator" (which in many cases will be very wrong) there's 40 translators that will commit to the same single file. I can tell you that the number of translators that I know (and hence trust) is significantly lower than 40. So this is a real problem, and for the amount of people it affects alone a different problem than for source files in a project. > I admit that more people on the same file are likely to have more conflicts > but that's only a theoretical problem or how often do translations change? I update translations daily. Not all of them, mind you. :-) For most translations, I tend to revisit them once a month on average while doing my daily round of updates, I believe (if they have changed). But I know that this isn't entirely uncommon, and a dozen of translators that do the same and/or add new translations and I have a whole bunch of cvs commits in the mean time that I have to cvs diff to inspect when I revisit. I'd rather not have to do that. > > Such a file will easily become one of the most committed > > files in gimp CVS, > > Okay, the most changed file is definitely the ChangeLog; who often > do you think there were conflicts? I had a couple (4 or 5) including > my more active time but Sven and Mitch can surely tell you how > often it occured to them in the last few months - just to give you > an idea how likely problems here are. Yes, but that's the very nature of the ChangeLog. It is *supposed* to be edited with every commit. Also, ChangeLogs are mostly for developers. Not many people don't cry or flame if there is a typo or a tab or dot is missing. However, if something is wrong in a translation, which usually is immediately visible to a large number of end users, that's another matter. > > and the danger of someone accidentally or > > intentionally messing with someone elses translation without permission > > becomes much more imminent. > > Don't think so. It's about as easy to touch an .po file. But in that case I can at least easily spot it! I thought I had already explained that it is the easy and early detection of other people's grateful unannounced changes to my translations I want to keep. Why do you think I use an $Id$ tag in all my po files? > > much (and thus removing another translation) when for example cutting > > Yes, mistakes happen, but also in other sources. Surely, but the problem is worse with translations. If you accidentally remove a line too much in the source, chances are big that you will notice that when compiling to test your changes. If other people edit a .desktop or XML file directly and accidentally cut away the line with my translation, it will not get detec
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
I think that regardless of what the original format is, translators should be given and work with po files. Christian Rose is right in his reasons. I have a few more to add. 1) The translator can't accidentally edit the wrong place and mess up. 2) It is what translators are used to working with and comfortable working with. We should give the translators something they can easily work with and can get lots of help on. It is a lot easier than having to write directions, risk having someone mess up the entire file, or have to answer a lot of questions. Using po just plain makes sense. Prof: Seriously here... are you a translator? I think you need to consider the experience that menthos has with this situation. If we consider what we might end up with in the future (many more tips, more complicated tips, more languages), it makes sense to plan po right now. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Sven ... [EMAIL PROTECTED] (2001-10-07 at 1656.37 +0200): > > hmm, wouldn't it be nicer to use the following instead ? > > > > > This is the first trip. > > > This is the second trip and it has bold text. > > > This is the last trip. Now, you are on your own. > > > > I'm not sure however why you want the tips to be numbered since it will > only make it more difficult to a new insert tip. If your goal is to be > able to refer to a certain tip, I'd suggest using unique names or ids > instead. The order of tips is already well-defined by the order they > appear in the file. > Looks much better than mine. Maybe I lack the imagination to remember today the tip that was presented yesterday without the number. I trust your judgment that it can be done, however. I am trying to follow the developer mail these last few days. Has a decision been made? thanks for your help, carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: > > Dia uses intltool/xml-i18n-tools for sheet files. > > That's new then. They didn't when I was translating the sheets. Then you should take a new look. It certainly does today. > > Because one of the fundamentals of easy translation is simply to have > > the original text handy. This is so you can easily compare the original > > and the translation, and ensure that the translation is entirely > > correct. I have to visually compare the strings many times during the > > translation of a single message, and at least twice: first to interpret > > the message I'm about to translate, and finally to compare what I wrote > > with the original so nothing got lost or added or any meaning changed in > > the translation. > > That's the same with the proposed XML format, just that all translations > are within one file and thus the unnecessary redundancy is gone. It's not the same, for the reasons I mentioned below. > > If you add a large number of translations to a single file and expect me > > to edit it, I have to skip a large number of unrelevant "garbage" (since > > I'm usually not at all interested in the other translations) just to > > compare the original and my translation. This makes the process of > > visually verifying translations harder. > > Okay, but then again it's just a matter of tools. I believe EMACS can > fold the unwanted ones away as can do VIM 6.0 and if necessary you > can use any XML editor of choice. Why should I have to use a special XML editor? How does the editor know what language I want to edit, and how does it automatically filter away everything else except the original string and my language? Do you believe everyone uses VIM or has the desire to be forced to do so? > > Another more dangerous thing is encodings. Multiple encodings in a > > single file don't mix well. > > UTF-8 rules. While I have to agree, you should probably have read a bit further. I mentioned the problems of using UTF-8 further down. > > I've got bitten too many times by other > > translators accidentally saving the whole file with their encoding and > > thus ruining my and many other's translations. Actually this was one of > > the most important reasons why we went away from editing .desktop files > > directly in GNOME: With hundreds of translators, the danger of someone > > accidentally doing this became very imminent (happened quite frequently) > > and it became a pain to ensure that translations weren't broken because > > of simple "accidents" like this. Also, it became a mess to "clean up" > > since effectively all translators had to be contacted to verify that > > their translations were still correct after such an accident. > > We live in a global world and we should act like that. The different > 8bit encodings are from a time where people cared very much about space > and not so much about internationalisation but this is not longer the > case; I believe that anything but UTF-8, Unicode and ASCII is futile and > will even be more in the future. Surely all translators are bound to agree with you. All incompatible 8bit encodings are a nightmare, and UTF-8 is the future. But that doesn't change the fact that we live with the tools we have today. We cannot stop translating or reduce the pace of translations until we live in a UTF-8 clean world, because simply there may never be such a world, and it is out of our control as translators, and for most idividual developers too, I'd imagine. It will be a long conversion process, and we have to support multiple encodings during that time. We can already store translations in UTF-8 today, but editing them is another matter. Also, the encoding problem remains to be only one of the problems with your solution. > > While enforcing the use of UTF-8 solves the encodings problem, it is not > > feasible for many other reasons. One is simply the lack of support in > > many editors and many other text processing tools (and terminals and so > > on). > > That's true. But what you're suggesting will only work for 8bit charsets > anyway; this broken software will most likely also fail for 2byte > charsets. Or do you want to exclude them? I do not understand what you are suggesting here. What's broken? iconv (which gettext and intltool uses) handles conversion of multibyte characters just fine. > > Effectively enforcing a particular editor hasn't worked yet, and > > probably never will, and it will probably take more time until all > > editors natively support UTF-8. > > The good ones already do and the bad ones never will; So you're saying that Emacs and many other editors are bad? Please don't turn this into an editor war. > there's still the possibility to escape those characters and then you'll have > pure ASCII. Escaping isn't realistic at all. I suspect your experience with having to write large amounts of text in your native language and escaping all non-ASCII characters is limited. It plain sucks for more ways than is
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sun, Oct 07, 2001 at 03:30:06PM +0200, Daniel Egger <[EMAIL PROTECTED]> wrote: > > our parser isn't homebrewn and is much better supported by glib than XML > > is. s-expressions are in my opinion easier to read and write for humans > > Knowing that you're an EMACS user I definitely think this statement > could be true. :) I for one keep the right to think different(TM), > though. Sven, he _does_ have a point here ;) XML at least looks familiar (after all, HTML is a widely known XML applikation) to many people, while lithp isn't so well-known or used outside the hackers circles. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sun, Oct 07, 2001 at 02:46:35PM +0200, Daniel Egger <[EMAIL PROTECTED]> wrote: > > really??? > I've heard there are Perl hacks as well. :) There are hacks for a lot of other languages/environments ;) The shortcoming of gettetx lies not int he parsing and input format... > > which would be easy, nice and probably very small. > Yes, but not very versatile... Why? It contains the tips and a minimum amoutn of clutter. If you equate evrsatile == xml because everybody claims to support it I disagree completely. > Also agreed, the disadvantage with the headers is that the messages > are static after compilation while it's quite easy to extend XML and > test it without having to recompile the application. Yeah, but a) nobody does that (right)? and b) this could be said for ltos of other things. Just as SGML was so feature-rich that nobody knew or used all its features we might not need to make everything run-time-configurable. Compare this to the trend of adding 10k of module loading and interfacing code to about each and every program nowadays where it doesn't make sense (pluggable protocol modules for lftp? get real... ;) > The problem with SGML is that it's too complex to grok completely and > that's why a large amount of people simply ignored it; XML is a subset That's a story I never heard of before. The reson SGML was not used is because it was very powerful and complex to implement. For humans it is easy to grok. You are comparing sgml with xml-applications. I could just claim that most sgml-applications are much easier to grok for humans than xml namespaces or schemas. > of SGML which was defined with ease-of-use in mind and that makes it Where do you get the idea that XML was done for ease-of-use? And why do you apply ease-of-use to humans, while XML was designed to be easy-to-use in applications (as opposed to SGML). one of the goals of xml is: XML documents should be human-legible and reasonably clear. this doesn't sound too encouraging, no? yes, it was a goal to keep xml "human", but this is a minor goal, others (ease-of-use for machines!) were more important. Anyways, it's getting off-topic and I'll keep it there ;) > Exactly. If we decide to use XML, we should do so consistently. Also we > can neglect the overhead in this case; in fact I believe that using > GMarkup is bloatfree or even better if we throw out the configparser for > instance. Fully agreed. Just somebody needed to code it ;) Ha, not me, not me, I am a lazy lamer ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: > > I'm not not exagerating. A typical tip consists of multiple lines (2 to 5) > > and you can't translate them line by line. My typical emacs setup shows > > about 42 lines, while the typical distance between the original tip and the > > translation will be around 40 to 100 lines with the solution you proposed > > (not accounting for empty lines to achieve better readability). I don't > > consider this a practical solution and I think Christian expressed the same > > opinion independently of my mail. > > Can't you configure EMACS to only show relevant parts of the file? We > could contribute such a configuration to make it easier to work with > the translations. I could also write one for vim FWIW. Good XML editor > can also show only relevant parts of a file with specified attributes > set. For all intents and purposes, this seems to me like the very wrong (and broken, since it would only work for one editor, and still doesn't solve other problems of keeping them in the same file) way to tackle the real problem. The real solution is simply to not force all translations to be edited in the same file. They can however be stored in the same generated file so that the application can easily access the data, but for humans it's easier to have this data split up when editing. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 17.25 schrieb 1002468356: > XML schema has only become a W3C recommendation lately and is > probably far from being finally standardized. AFAIK there are only > few (if any at all) usable tools out there that can validate XML > schema. I think you meant to say DTD here ?! A DTD would be good for the start, you're right. I was just riding on the hype a bit to much. :) -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 16.42 schrieb 1002465752: > I'm not not exagerating. A typical tip consists of multiple lines (2 to 5) > and you can't translate them line by line. My typical emacs setup shows > about 42 lines, while the typical distance between the original tip and the > translation will be around 40 to 100 lines with the solution you proposed > (not accounting for empty lines to achieve better readability). I don't > consider this a practical solution and I think Christian expressed the same > opinion independently of my mail. Can't you configure EMACS to only show relevant parts of the file? We could contribute such a configuration to make it easier to work with the translations. I could also write one for vim FWIW. Good XML editor can also show only relevant parts of a file with specified attributes set. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 16.50 schrieb 1002466228: > our parser isn't homebrewn and is much better supported by glib than XML > is. s-expressions are in my opinion easier to read and write for humans Knowing that you're an EMACS user I definitely think this statement could be true. :) I for one keep the right to think different(TM), though. > than XML syntax which was never designed to be edited by hand. No, XML was designed to be parsed, written and validated by machines; that's true. However SGML was not, it was meant to be written by humans to keep structure in documents and since SGML is the father of XML this still remains true. > From the > users point of view, would you really prefer a XML format for gimprc over > the existing one? I certainly wouldn't. gimprc is not really the issue here, though I wouldn't it being an XML file. Let's talk about pluginrc instead. Using XML for gimprc would be more a consistency issue. > The GMarkup parser in glib-2.0 is a simple SAX-like parser interface, I know. > while libxml offers an alternative DOM interface. The question is what is better for this purpose. DOM would be perfect for config files though using SAX wouldn't be much of a problem either. > For simple purposes > we can definitely get away without libxml, more sophisticated XML > handling will certainly require it. Agreed. > I don't have strong feelings against > depending on libxml2 however it it becomes necessary. Sorry? -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: > First of all we should write an schema to make it validateable. XML schema has only become a W3C recommendation lately and is probably far from being finally standardized. AFAIK there are only few (if any at all) usable tools out there that can validate XML schema. I think you meant to say DTD here ?! Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 16.03 schrieb 1002463421: > Also, one important drawback of keeping all translations in one file in > CVS, and forcing translators to edit this file, is that it gets almost > impossible to verify the integrity of translations. As a translator and > creator and maintainer of the translation, I feel that it is important > that errors in my translation are my errors alone, and that I'm the only > one responsible for them. Translation errors introduced by other people > without permission are, well, "annoying" to say the least. It's quite tricky to introduce any errors in XML files and easy at the same time to fix them. CVS guarantees a certain amount of integrity so having conflicting changes is not a problem. AND: XML can be easily verified to be correct when there's a schema file, even remotely, and in theory the GNOME CVS server could be teached to only allow checkin of valid XML files. > With a whole bunch of different people committing to the same file, > verifying the integrity of individual translations becomes almost > impossible. It's not more of a problem then with several people working on other files concurrently; that's what CVS is for. I admit that more people on the same file are likely to have more conflicts but that's only a theoretical problem or how often do translations change? > Such a file will easily become one of the most committed > files in gimp CVS, Okay, the most changed file is definitely the ChangeLog; who often do you think there were conflicts? I had a couple (4 or 5) including my more active time but Sven and Mitch can surely tell you how often it occured to them in the last few months - just to give you an idea how likely problems here are. > and the danger of someone accidentally or > intentionally messing with someone elses translation without permission > becomes much more imminent. Don't think so. It's about as easy to touch an .po file. > much (and thus removing another translation) when for example cutting Yes, mistakes happen, but also in other sources. > and pasting, and there's always the danger of someone wanting to > "improve" another translation, without seeing the need to ask first. You fear competition? Well, I pissed off some evolution people while fixing their DocBook->HTML converter once and they didn't want to have it fixed for some reason (heck, they even wrote a contributors killerscript because of that) so I left it alone and let them fix their own crap and decided not to use realtime translation for gimp-help. What's the lesson? Some people have no sense of cooperation so better let them alone. It's the same with translations; some people don't want contributors for their files and others don't mind when people have something to contribute but that's not really a matter of the fileformat. > With a single file, the only way of verifying the integrity of my own > translations is basically having to resort to 'cvs diff' after every > single commit to this file in CVS, which will hardly be practical. > With separate po files, commits to "my" file are much more rare, and I > basically only have to ensure that the last committer was me (easily > doable by putting in a CVS "$Id$" tag in the file) to be sure that the > translation hasn't been changed by someone else without permission. Ayee, reading this lines really annoys me. GIMP grew to such a beautiful project because of cooperation. Egoism and arrogance are definitely wrong here; if you don't want your sources to be touched then keep them closed source. Competition is good and the fittest translation will survive and that's not something fixed one person can decide, in doubt people will need to discuss about it. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Son, 2001-10-07 um 15.32 schrieb 1002461554: > Dia uses intltool/xml-i18n-tools for sheet files. That's new then. They didn't when I was translating the sheets. > Because one of the fundamentals of easy translation is simply to have > the original text handy. This is so you can easily compare the original > and the translation, and ensure that the translation is entirely > correct. I have to visually compare the strings many times during the > translation of a single message, and at least twice: first to interpret > the message I'm about to translate, and finally to compare what I wrote > with the original so nothing got lost or added or any meaning changed in > the translation. That's the same with the proposed XML format, just that all translations are within one file and thus the unnecessary redundancy is gone. > If you add a large number of translations to a single file and expect me > to edit it, I have to skip a large number of unrelevant "garbage" (since > I'm usually not at all interested in the other translations) just to > compare the original and my translation. This makes the process of > visually verifying translations harder. Okay, but then again it's just a matter of tools. I believe EMACS can fold the unwanted ones away as can do VIM 6.0 and if necessary you can use any XML editor of choice. > Another more dangerous thing is encodings. Multiple encodings in a > single file don't mix well. UTF-8 rules. > I've got bitten too many times by other > translators accidentally saving the whole file with their encoding and > thus ruining my and many other's translations. Actually this was one of > the most important reasons why we went away from editing .desktop files > directly in GNOME: With hundreds of translators, the danger of someone > accidentally doing this became very imminent (happened quite frequently) > and it became a pain to ensure that translations weren't broken because > of simple "accidents" like this. Also, it became a mess to "clean up" > since effectively all translators had to be contacted to verify that > their translations were still correct after such an accident. We live in a global world and we should act like that. The different 8bit encodings are from a time where people cared very much about space and not so much about internationalisation but this is not longer the case; I believe that anything but UTF-8, Unicode and ASCII is futile and will even be more in the future. > While enforcing the use of UTF-8 solves the encodings problem, it is not > feasible for many other reasons. One is simply the lack of support in > many editors and many other text processing tools (and terminals and so > on). That's true. But what you're suggesting will only work for 8bit charsets anyway; this broken software will most likely also fail for 2byte charsets. Or do you want to exclude them? > Effectively enforcing a particular editor hasn't worked yet, and > probably never will, and it will probably take more time until all > editors natively support UTF-8. The good ones already do and the bad ones never will; there's still the possibility to escape those characters and then you'll have pure ASCII. You can even let them convert automatically if you really want. > encodings problem again: If you force me to use UTF-8, I have to > maintain several translation memories instead of a single one, one for > each encoding. Huh? You're trying to tell me that UTF-8 will mess this up? How are you handling this right now then with different encodings? > So while the storage of all translations in UTF-8 solves its shares of > problems, it creates new ones for translators. This is why intltool lets > translators use their encoding when translating, and converts it to > UTF-8 when needed. Okay, that's fine with me. > And that is still a problem, as explained above. 15 lines of irrelevant > text inbetween every single message and its translation into my language > makes verifying translations an unnecessary difficult burden. See above. Try the folding feature of vim 6.0, it's really cool. > Dia uses intltool now, so it seems they have recognized the problems the > translators had. I haven't noticed that "problems", maybe it's only my imagination that XML is easy to handle. > It is necessary. po format and gettext have many important features that > translators depend upon, something I have previously experienced that > almost every translator knew. important features in gettext? > gettext has evolved. It has much of the features that translators need. > And, as you admit, it's industry standard. If you want to replace it, > you'd better write a better and fully compatible alternative (since a > lot of tools across many platforms are designed to work with this > industry standard), while keeping all existing features. I beleive this > is where people use the phrase "show me the code". Okay, I can hack up an application using XML for that purpose in almost no time. While XML w
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Carol Spears <[EMAIL PROTECTED]> writes: > It seems that all any decent site would need would be this: > > > > > >0 > >This is the first trip. > > > >1 > >This is the second trip and it has bold text. > > > >2 > >This is the last trip. Now, you are on your own. > > hmm, wouldn't it be nicer to use the following instead ? This is the first trip. This is the second trip and it has bold text. This is the last trip. Now, you are on your own. I'm not sure however why you want the tips to be numbered since it will only make it more difficult to a new insert tip. If your goal is to be able to refer to a certain tip, I'd suggest using unique names or ids instead. The order of tips is already well-defined by the order they appear in the file. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: > If we go for XML (which is definitely a good idea) we should use it > also for our config files and drop the homebrewn parser. Maybe we can > get away with simply using the new glib-2.0 functions instead of adding > an dependency on libxml or similar. our parser isn't homebrewn and is much better supported by glib than XML is. s-expressions are in my opinion easier to read and write for humans than XML syntax which was never designed to be edited by hand. From the users point of view, would you really prefer a XML format for gimprc over the existing one? I certainly wouldn't. The GMarkup parser in glib-2.0 is a simple SAX-like parser interface, while libxml offers an alternative DOM interface. For simple purposes we can definitely get away without libxml, more sophisticated XML handling will certainly require it. I don't have strong feelings against depending on libxml2 however it it becomes necessary. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 22.59 schrieb 1002401996: > > To use gettext on has to have a file with C syntax; > really??? I've heard there are Perl hacks as well. :) > which would be easy, nice and probably very small. Yes, but not very versatile... > anyways, if we use another format (xml) and have all the i18n tools for > that we should use them. just using xml because everybody else does it > doesn't make sense. Agreed. > and parsing a header file can be as easy as parsing xml. Also agreed, the disadvantage with the headers is that the messages are static after compilation while it's quite easy to extend XML and test it without having to recompile the application. > cvs works fine as long as a certain structure is used. for human-edited > files there should be no problem. Exactly. All humanreadable files are perfekt candidates for CVS use, while binaries are not. > it's difficult to implement but it's for humans to write. my motto is "the > computer exists to support you, not vice versa". smgl is designed to be > efficient for humans, not neccessarily easy to parse, or to implement. The problem with SGML is that it's too complex to grok completely and that's why a large amount of people simply ignored it; XML is a subset of SGML which was defined with ease-of-use in mind and that makes it quite attractive though many people (and especially big companies) are overestimating its use. However for XML there are good tools available nowadays and that makes it very easy to implement. > believe it or not, xml was designed to be processed efficiently by > machines, not for humans. the current hype for xml comes from the > availability of tools, not from it being nicer for humans (which is not > true). xml is *still* human read- and writable, which is a great thing in > itself, though. I do believe in that. :) > > XML was designed to have a standarised markup language to allow > > human readable, verificable and interchangeable files. Don't follow > "human-verifacable" and "human-interchangeable"? can't follow you here. Sorry, the human belongs to readable only. > Make it vice versa: If we use xml anyways (for config files) then it's > natural to use it for other (textual) data files as well. Exactly. If we decide to use XML, we should do so consistently. Also we can neglect the overhead in this case; in fact I believe that using GMarkup is bloatfree or even better if we throw out the configparser for instance. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: > Am Sam, 2001-10-06 um 19.05 schrieb 1002387943: > > > > 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. > > Me not. I'm always a step ahead. Would you mind telling me why you want > to change the tips format, I must have missed that. just to make it easier to translate it and maintain translations. At the moment it reuqires a lot of work to merge changes in the original tips into translations. We have been asked to change this if possible. > > 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. > > Please stop exagerating; a person that doesn't have a monitor that is > able to display 26 lines at once is pretty poor anyway. I'm not not exagerating. A typical tip consists of multiple lines (2 to 5) and you can't translate them line by line. My typical emacs setup shows about 42 lines, while the typical distance between the original tip and the translation will be around 40 to 100 lines with the solution you proposed (not accounting for empty lines to achieve better readability). I don't consider this a practical solution and I think Christian expressed the same opinion independently of my mail. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 22.30 schrieb 1002400250: > It seems that all any decent site would need would be this: > > > > >0 > >This is the first trip. > First of all we should write an schema to make it validateable. Why do you want to have the numbers in there? Are the tips important enough to be shown in a specified order? But something like this is what I would imagine. -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Replying to myself since I forgot some things... Christian Rose wrote: > While enforcing the use of UTF-8 solves the encodings problem, it is not > feasible for many other reasons. One is simply the lack of support in > many editors and many other text processing tools (and terminals and so > on). Effectively enforcing a particular editor hasn't worked yet, and > probably never will, and it will probably take more time until all > editors natively support UTF-8. Also, many translators use "translation > memories", that is large po format databases with existing translations, > created and managed by special translation memory. s/special translation memory/special translation memory tools/ Also, one important drawback of keeping all translations in one file in CVS, and forcing translators to edit this file, is that it gets almost impossible to verify the integrity of translations. As a translator and creator and maintainer of the translation, I feel that it is important that errors in my translation are my errors alone, and that I'm the only one responsible for them. Translation errors introduced by other people without permission are, well, "annoying" to say the least. With a whole bunch of different people committing to the same file, verifying the integrity of individual translations becomes almost impossible. Such a file will easily become one of the most committed files in gimp CVS, and the danger of someone accidentally or intentionally messing with someone elses translation without permission becomes much more imminent. It's easy to accidentally remove a line too much (and thus removing another translation) when for example cutting and pasting, and there's always the danger of someone wanting to "improve" another translation, without seeing the need to ask first. With a single file, the only way of verifying the integrity of my own translations is basically having to resort to 'cvs diff' after every single commit to this file in CVS, which will hardly be practical. With separate po files, commits to "my" file are much more rare, and I basically only have to ensure that the last committer was me (easily doable by putting in a CVS "$Id$" tag in the file) to be sure that the translation hasn't been changed by someone else without permission. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: > IF we need to add another dependency it has to be worth it. Solving > problems by using XML for everything seems only clever to me. It does > not make sense to use XML for tip files while plug-ins still keep > in beeing broken (in the localisation context). > > > 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. > > Really? Everything is were it belongs to and nothing is used within > wrong context and, last but not least, its extensible and that even > easily. Dia uses intltool/xml-i18n-tools for sheet files. > > The tips file is 9 kB now. With 15 supported languages (how many on > > the way?), that would become 135 kB. > > In contrary to po files untranslated messages are simply nonexistant. > And you forget one thing: All .po files together are by definition > bigger since the original text is repeated within every single file. And that is for a good reason (see below)... > > 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. > > Why not? Because one of the fundamentals of easy translation is simply to have the original text handy. This is so you can easily compare the original and the translation, and ensure that the translation is entirely correct. I have to visually compare the strings many times during the translation of a single message, and at least twice: first to interpret the message I'm about to translate, and finally to compare what I wrote with the original so nothing got lost or added or any meaning changed in the translation. This means that the original string and the translation should be as close as possible to each other, and this is why po format has the messages this way: First the original, and immediately below the space for the translation. If you add a large number of translations to a single file and expect me to edit it, I have to skip a large number of unrelevant "garbage" (since I'm usually not at all interested in the other translations) just to compare the original and my translation. This makes the process of visually verifying translations harder. Another more dangerous thing is encodings. Multiple encodings in a single file don't mix well. I've got bitten too many times by other translators accidentally saving the whole file with their encoding and thus ruining my and many other's translations. Actually this was one of the most important reasons why we went away from editing .desktop files directly in GNOME: With hundreds of translators, the danger of someone accidentally doing this became very imminent (happened quite frequently) and it became a pain to ensure that translations weren't broken because of simple "accidents" like this. Also, it became a mess to "clean up" since effectively all translators had to be contacted to verify that their translations were still correct after such an accident. While enforcing the use of UTF-8 solves the encodings problem, it is not feasible for many other reasons. One is simply the lack of support in many editors and many other text processing tools (and terminals and so on). Effectively enforcing a particular editor hasn't worked yet, and probably never will, and it will probably take more time until all editors natively support UTF-8. Also, many translators use "translation memories", that is large po format databases with existing translations, created and managed by special translation memory. I use such a memory with all my existing translations (it's 6.4 MB of text) to automatically generate a skeleton for all new po format translations, with messages similar to existing translations already translated. Aside from the fact that this won't work if you don't use po format, this points out the encodings problem again: If you force me to use UTF-8, I have to maintain several translation memories instead of a single one, one for each encoding. So while the storage of all translations in UTF-8 solves its shares of problems, it creates new ones for translators. This is why intltool lets translators use their encoding when translating, and converts it to UTF-8 when needed. > And where do you get the 30 from? If you have 15 languages then > you'll have at maximum 15 times the original text to skip. And that is still a problem, as explained above. 15 lines of irrelevant text inbetween every single message and its translation into my language makes verifying translations an unnecessary difficult burden. > Beeing a translator myself (and in fact also one of the one of the DIA sheets) > I can tell that this is not as evil as it might look. Dia uses intltool now, so it seems they have recognized the problems the translators had. > > so I
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 07:56:15PM +0200, Daniel Egger <[EMAIL PROTECTED]> wrote: > To use gettext on has to have a file with C syntax; really??? > to have a header file where the original messages are defined and > then use gettext with that. which would be easy, nice and probably very small. anyways, if we use another format (xml) and have all the i18n tools for that we should use them. just using xml because everybody else does it doesn't make sense. and parsing a header file can be as easy as parsing xml. > CVS seems fine to me, what would you need a tool for? There's no > need to merge catalogtemplates with existing catalogs in XML world. cvs works fine as long as a certain structure is used. for human-edited files there should be no problem. > That's correct. Though there are much fewer tools for SGML than for XML; > why? Because SGML was and still is too bloated for many uses. it's difficult to implement but it's for humans to write. my motto is "the computer exists to support you, not vice versa". smgl is designed to be efficient for humans, not neccessarily easy to parse, or to implement. > > XML apps are usually not meant to be read and edited by humans, > > Huh? believe it or not, xml was designed to be processed efficiently by machines, not for humans. the current hype for xml comes from the availability of tools, not from it being nicer for humans (which is not true). xml is *still* human read- and writable, which is a great thing in itself, though. > Great. Show me the specs... I'm not talking about de-facto or so > called "industry-standards". gettext is such a crap that I really > doubt there was a standarisation process which led to a proper > specification. ;) gettext is still much better then the "standard" (message catalogs ;) > XML was designed to have a standarised markup language to allow > human readable, verificable and interchangeable files. Don't follow "human-verifacable" and "human-interchangeable"? can't follow you here. > the hype but choose the best of all worlds and that's where XML > chimes in; sure you can use this approach here and the other there > but in the end you're just wasting your own time by thinking of new > formats and algorithms to parse them. xml is certainly betetr then about _any_ ad-hoc format. On Sat, Oct 06, 2001 at 12:11:18AM +0200, Daniel Egger <[EMAIL PROTECTED]> wrote: > If we go for XML (which is definitely a good idea) we should use it > also for our config files and drop the homebrewn parser. Make it vice versa: If we use xml anyways (for config files) then it's natural to use it for other (textual) data files as well. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 07:33:28PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > have done it before. I can see at least one more advantages of using an > external file: The tips don't stay in memory all the time. So we should > probably go for it. (just a sidenote: if tips were compiled-in and large enough for this to be relevant, they would still not stay in memory all the time. guess that the parser would take up more memory ;). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 06:06:19PM +0200, Guillermo S. Romero / Familia Romero wrote: >Maybe next version should have Wilberpy as helper. The concept image >was nice: "I see you want to draw a straight line". Or rather: "I see you erase. Let me erase the rest of the image for you, then save." *g* /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Die, 2001-10-02 um 18.57 schrieb 1002041867: > I'm all for it. I have already considered doing such a change in gimp > HEAD. I'd favor a separate translation domain for the tips since we > could avoid to bind to this domain until the tips dialog is actually > shown. A header file with static strings should probably do the trick > most easily or do you think an XML file would give any advantages? If we go for XML (which is definitely a good idea) we should use it also for our config files and drop the homebrewn parser. Maybe we can get away with simply using the new glib-2.0 functions instead of adding an dependency on libxml or similar. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 19.05 schrieb 1002387943: > > 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. Me not. I'm always a step ahead. Would you mind telling me why you want to change the tips format, I must have missed that. > 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. Do we have translations for all tips in 26 languages? XML don't grow with the number of languages unlike the po-directory. And 5000 lines are still a reasonable number considering that the German catalog for app has more than 6000 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. Please stop exagerating; a person that doesn't have a monitor that is able to display 26 lines at once is pretty poor anyway. > 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. That's a good point. On the other hand we might want to go for UTF-8 though instead of having a whole bunch of different encodings, and then there's still the possibility to escape special characters. > 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. Hm, if you really insist on using the xml-i18n-tools that'd be fine for me; it's just a small detail of the whole process. > 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. It works for now though it was quite some action when we implemented it and it's still not sure it will work in the future; that's a very fragile piece of code. However if you think about the plugin problem that has been discussed every now and then heavily this is the only way to solve it (well, at least no one mentioned a better one as of yet). > I don't think we want to force plug-in developers into using glade. Me neither, but something alike would be pretty cool. Since Mitch and you already unified the plugins a quite a nice way this would be the crown to it. :) I'll address the rest of your mail in another email... -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 17.23 schrieb 1002381819: > Whatever the solution regarding GIMP tips turns out to be, translators > want to be able to translate them from within po files. I hope everyone > has agreed on that :) not really. > If you go for XML, I'd recommend using intltool. It's a set of tools > designed exactly for this purpose. Since gettext itself doesn't have a > clue about XML, intltool works as a middle layer that extracts strings > marked for translation in the XML and adds them to header files, so that > xgettext can extract them and put them in a pot. The reverse process is > usually done at build time, and all the translations merged back into > the original XML file. > You can find intltool in the xml-i18n-tools module in CVS. Okay, so why would one want this heavy conversion action? If the only purpose is to have only one editable catalog instead of several files and people really need that then okay... > I as a translator also prefer po format... I doubt there is any > translator that wouldn't. I don't. I don't care which format the translations have to be in. XML is about as easy as .po... -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 12.51 schrieb 1002365476: > No prof. You've got it wrong. em means emphasis. It means the text > should be given some sort of emphasis. The stylesheets then determine > what that emphasis is. (italics, color change, etc.) No, is HTMLism. There's no in DocBook for example, it's there Though the look of can be changed by an CSS stylesheet it is not exactly the same as ... -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Sam, 2001-10-06 um 14.33 schrieb 1002371616: > > 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. To use gettext on has to have a file with C syntax; the idea is to have a header file where the original messages are defined and then use gettext with that. > 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. IF we need to add another dependency it has to be worth it. Solving problems by using XML for everything seems only clever to me. It does not make sense to use XML for tip files while plug-ins still keep in beeing broken (in the localisation context). > 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. Really? Everything is were it belongs to and nothing is used within wrong context and, last but not least, its extensible and that even easily. > The tips file is 9 kB now. With 15 supported languages (how many on > the way?), that would become 135 kB. In contrary to po files untranslated messages are simply nonexistant. And you forget one thing: All .po files together are by definition bigger since the original text is repeated within every single file. > We'd need a tool to merge changes, or would CVS be enough? CVS seems fine to me, what would you need a tool for? There's no need to merge catalogtemplates with existing catalogs in XML world. > 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. Why not? And where do you get the 30 from? If you have 15 languages then you'll have at maximum 15 times the original text to skip. Beeing a translator myself (and in fact also one of the one of the DIA sheets) I can tell that this is not as evil as it might look. > 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. That's correct. Though there are much fewer tools for SGML than for XML; why? Because SGML was and still is too bloated for many uses. > XML apps are usually not meant to be read and edited by humans, Huh? > so I expect you have got a tool for the translators in mind? If necessary I can hack something up but it should not be necessary. I really don't see the big difference to hacking a .po file. > gettext is also a standard. Great. Show me the specs... I'm not talking about de-facto or so called "industry-standards". gettext is such a crap that I really doubt there was a standarisation process which led to a proper specification. > XML was developed to give marketdroids a > new fad to woo, whereas gettext was developed to let translators do > their thing. XML was designed to have a standarised markup language to allow human readable, verificable and interchangeable files. Don't follow the hype but choose the best of all worlds and that's where XML chimes in; sure you can use this approach here and the other there but in the end you're just wasting your own time by thinking of new formats and algorithms to parse them. > I know which I as a translator prefer. Allright then, I'll keep it in mind. > If we tarred the tips directory, would that solve your 'many files' > problem? ;-) I don't care about the amount of files in special directories or the final tarball, I care about the number of libraries in /usr/lib and hundreds of files /usr/share/locale/*/LC_MESSAGES though -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi,
"Branko Collin" <[EMAIL PROTECTED]> writes:
> What is 'the header kludge'? I never got that bit.
I'll try to summarize what has been discussed so far. At the moment,
there are two proposed places to store the original english tips.
Either use a C file or a header that would look something like this:
const gchar *tips[] =
{
N_("This is the first tip."),
N_("This is the second tip and it has bold text."),
N_("This is the last tip. Now, you are on your own.")
};
gint n_tips = G_N_ELEMENTS (tips);
or make this a simple XML file like for example:
This is the first tip.
This is the second tip and it has bold text.
This is the last tip. Now, you are on your own.
We could then use existing tools to create po files from these sources
to ease translators work. The XML solution has the advantage that we
could use the same file for other purposes (www.gimp.org) but it requires
us to write a simple parser. I can assure you however that this parser
can be done in less than 10 minutes using GMarkup from glib-2.0 and I
have done it before. I can see at least one more advantages of using an
external file: The tips don't stay in memory all the time. So we should
probably go for it.
If we really want to use the file in other places (web-sites), someone
involved there needs to come up with a proposal for the format.
Otherwise I'd say that the simple format using the Pango Text Attribute
Markup Language directly as outlined above should be good enough. For
your convenience here's the link again:
http://developer.gnome.org/doc/API/2.0/pango/pangomarkupformat.html
Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Daniel Egger <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Branko Collin wrote: > > > 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. I agree about that, however I'm not sure if this isn't what's already been discussed. Whatever the solution regarding GIMP tips turns out to be, translators want to be able to translate them from within po files. I hope everyone has agreed on that :) This can be done several ways, either by adding the tips as C headers and mark them for translation, or using a XML file format and intltool (formerly known as xml-i18n-tools), or some other solution. If you go for XML, I'd recommend using intltool. It's a set of tools designed exactly for this purpose. Since gettext itself doesn't have a clue about XML, intltool works as a middle layer that extracts strings marked for translation in the XML and adds them to header files, so that xgettext can extract them and put them in a pot. The reverse process is usually done at build time, and all the translations merged back into the original XML file. You can find intltool in the xml-i18n-tools module in CVS. > > 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? ;-) I as a translator also prefer po format... I doubt there is any translator that wouldn't. However, if you use something like intltool, there's no reason you can't have both. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On 5 Oct 2001, at 16:06, Carol Spears wrote: > Okay, everything I know about XML I learned by osmosis (ie, i slept > with XML in a Nutshell under my pillow), but XML seems to make sense > and be a lot less rigid than SGML. To the contrary, XML is way more rigid than SGML, that is its defining quality. XML = rigid(SGML). What they did was throw out a whole bunch of features that not many people were using, then tighten the rules. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
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 [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, 2001-10-06 at 12:49, Daniel Egger wrote: > On Sat, Oct 06, 2001 at 02:06:15AM -0600, Nathan C Summers wrote: > > > We can also use XML for its original purpose -- a markup language. Even > > just adding an emphasis tag can allow tip writers to be much more > > expressive. > > That's an abuse of a tag. is a stylistic tag from the HTML days, > with XML text should be marked like: tag. The actual rendering is up to the stylesheets or preferences of the > user/developer. But yes: In theory you're right. No prof. You've got it wrong. em means emphasis. It means the text should be given some sort of emphasis. The stylesheets then determine what that emphasis is. (italics, color change, etc.) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 02:06:15AM -0600, Nathan C Summers wrote: > We can also use XML for its original purpose -- a markup language. Even > just adding an emphasis tag can allow tip writers to be much more > expressive. That's an abuse of a tag. is a stylistic tag from the HTML days, with XML text should be marked like: But I was thinking of adding the ability to have small graphics in the tip > of the day. Am I the only one that finds it odd that GIMP is an image > manipulation program, yet the tips are all in text? Even the > database visualization app I worked on over the summer could embed small > graphics in the tip of the day, although in that app it was used mostly to > display which button does which thing. No, I think the tips should be kept rather simple. But what I can imagine is a link to the correct sections in the manual to look up more information on the tip. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
> perhaps I'm imaging something wrong here, but I think graphics would be > overkill for the tips. Stuff like this belongs to the help pages if you > ask me. It would probably help to allow links to help pages in the tips > dialog and it would also be much simpler to implement than text flow > around image boxes (unless you want gimp to depend on gtkhtml2 for the > tips). I agree with Sven about images in tips. Maybe in the future, after we (we mainly means syngin) have finished documenting all the stuff that HAS to be documented, it might be nice to add some tutorial-like docs to the help stuff. Then the tips could link to some of that stuff. But I can definitely see a lot of potential in linking tips to the help. That way the tips can be little tidbits that then link into the help to give more information. I don't know that any of the help people have time to make changes like this in the present, but I can see a lot of potential in it for future development. It is nice to leave room for future development. bex ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Nathan C Summers <[EMAIL PROTECTED]> writes: > We can also use XML for its original purpose -- a markup language. Even > just adding an emphasis tag can allow tip writers to be much more > expressive. GTK+-2.0 allows some simple markup to be applied to labels and other text areas without too much hassle. Actually we don't even need to go for the XML file solution, we can simply use the XML-style markup tags in the text, no matter how we store it. Here's the API: http://developer.gnome.org/doc/API/2.0/pango/pangomarkupformat.html > But I was thinking of adding the ability to have small graphics in the tip > of the day. Am I the only one that finds it odd that GIMP is an image > manipulation program, yet the tips are all in text? Even the > database visualization app I worked on over the summer could embed small > graphics in the tip of the day, although in that app it was used mostly to > display which button does which thing. > > I think that small graphics could be used to great effects -- to make your > graphic look like , use the bumpmap plugin. OK, it would take a > little more text than that to make it work well, but you get the idea. perhaps I'm imaging something wrong here, but I think graphics would be overkill for the tips. Stuff like this belongs to the help pages if you ask me. It would probably help to allow links to help pages in the tips dialog and it would also be much simpler to implement than text flow around image boxes (unless you want gimp to depend on gtkhtml2 for the tips). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: > If you use XML for texts like tips or dialogparts then attributes > are being used for specifying the language the text is in. > > A tip might look like this: > Niemals GIMP schließen > Never close the GIMP > > DIA for instance uses something alike to implement modular extensions > to the graph set. > > 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. Not in CVS and not in the distribution. The file will get large and akward to edit. I don't think generation, compilation and installation of several files is a problem since there are good tools to do that. > 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? Actually I do have some ideas in this area and I think Ingo wanted to outline a plug-in description draft that uses XML. But the use of XML alone will not solve any our problems. After all it's only a markup language and there's nothing really new to it that you couldn't have done years ago. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
On 6 Oct 2001, Daniel Egger wrote: > Am Die, 2001-10-02 um 19.14 schrieb 1002042874: > > > there is probably no need for XML as there are no attributes etc. > > If you use XML for texts like tips or dialogparts then attributes > are being used for specifying the language the text is in. We can also use XML for its original purpose -- a markup language. Even just adding an emphasis tag can allow tip writers to be much more expressive. But I was thinking of adding the ability to have small graphics in the tip of the day. Am I the only one that finds it odd that GIMP is an image manipulation program, yet the tips are all in text? Even the database visualization app I worked on over the summer could embed small graphics in the tip of the day, although in that app it was used mostly to display which button does which thing. I think that small graphics could be used to great effects -- to make your graphic look like , use the bumpmap plugin. OK, it would take a little more text than that to make it work well, but you get the idea. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: > > No, as you say, a header file is probably the easiest solution, > > Actually if there was an XML parser this would be the simplest solution. > It is just that we'd need a parser and I haven't evaluated the GMarkup > part of the new glib yet. Ok. > > there is probably no need for XML as there are no attributes etc. > > If you use XML for texts like tips or dialogparts then attributes > are being used for specifying the language the text is in. > > A tip might look like this: > Niemals GIMP schließen > Never close the GIMP If you use a single file, that is true, yes. > DIA for instance uses something alike to implement modular extensions > to the graph set. > > 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 agree about the advantage over several files, but even a single Gimp Tips XML file would have to be generated (with translations from the PO files), probably with the help of intltool. But a single generated file is probably better than a whole lot of them, yes. > 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. Ok. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Die, 2001-10-02 um 19.14 schrieb 1002042874: > No, as you say, a header file is probably the easiest solution, Actually if there was an XML parser this would be the simplest solution. It is just that we'd need a parser and I haven't evaluated the GMarkup part of the new glib yet. > there is probably no need for XML as there are no attributes etc. If you use XML for texts like tips or dialogparts then attributes are being used for specifying the language the text is in. A tip might look like this: Niemals GIMP schließen Never close the GIMP DIA for instance uses something alike to implement modular extensions to the graph set. 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. 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. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Fre, 2001-10-05 um 21.47 schrieb 1002311231: > It is like the GIMP help. We write the help in DocBook SGML. It is SGML right now but is written with XML compatibility in mind so we would simply need to flip a switch (in every file that is) to have full XML. > It can be converted to cool stuff including PDF. > Pippin has been writing our SGML to PDF converter. If you don't mind to be corrected here: I wrote the SGML-TeX converter which is used for the PDF output by feeding the intermediate .tex file into pdflatex. pippin helped me with his TeX and layouting skills to make the output much better. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
> XML is supposed to make information more portable into the future, > right? > > GIMP is being used in classrooms lately, it would be nice if we have the > option to print all gimp documentation in any form we should choose. I'm not as familiar with XML conversion tools as I am with SGML, but I think they exist. It is like the GIMP help. We write the help in DocBook SGML. It can be converted to cool stuff including PDF. Pippin has been writing our SGML to PDF converter. It can also be converted to HTML. (Which is what gets done before it goes into the release right now anyway) (Sorry if the line wrapping is messed up. Evo is misbehaving) bex ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi Rebecca, [EMAIL PROTECTED] (2001-10-05 at 2030.20 +0200): > > > it would matter if you could name an advantage it would give us. I don't > > mind adding a simple XML-parser to GIMP-1.4 since it's pretty simple > > using GMarkup from GLib-2.0, but I don't want to do so without a good > > reason. > > hmm.. XML could be quickly converted to HTML and used on the web site as > a something-or-other? > XML is supposed to make information more portable into the future, right? GIMP is being used in classrooms lately, it would be nice if we have the option to print all gimp documentation in any form we should choose. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
> it would matter if you could name an advantage it would give us. I don't > mind adding a simple XML-parser to GIMP-1.4 since it's pretty simple > using GMarkup from GLib-2.0, but I don't want to do so without a good > reason. hmm.. XML could be quickly converted to HTML and used on the web site as a something-or-other? (actually it doesn't matter to me, I am just being silly) Could these tip dialogs providee "click to link" thingies to hand people over to GIMP help? Just wodnering if that might be useful in planning for the future. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Carol Spears <[EMAIL PROTECTED]> writes: > > I'm all for it. I have already considered doing such a change in gimp > > HEAD. I'd favor a separate translation domain for the tips since we > > could avoid to bind to this domain until the tips dialog is actually > > shown. A header file with static strings should probably do the trick > > most easily or do you think an XML file would give any advantages? > > > I vote for an XML file, if it matters. it would matter if you could name an advantage it would give us. I don't mind adding a simple XML-parser to GIMP-1.4 since it's pretty simple using GMarkup from GLib-2.0, but I don't want to do so without a good reason. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
[EMAIL PROTECTED] (2001-10-02 at 1857.47 +0200): > Hi, > > Christian Rose <[EMAIL PROTECTED]> writes: > > > Hmm, would it be possible to make GIMP tips translatable in a po file in > > the future? That would probably ease translation, since gettext has some > > nice features: it's easy to compare the original message and the > > translation, easy to spot messages that changed or new messages, and so > > on. > > The messages could be put in a header file, or an XML file of some sort > > (if you use intltool/xml-i18n-tools). If it's too much to put in > > gimp.pot, it could be a translation catalog of its own. > > > > What do you think? > > I'm all for it. I have already considered doing such a change in gimp > HEAD. I'd favor a separate translation domain for the tips since we > could avoid to bind to this domain until the tips dialog is actually > shown. A header file with static strings should probably do the trick > most easily or do you think an XML file would give any advantages? > I vote for an XML file, if it matters. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
