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
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
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 bbold/b 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 stdio.h
#include libgimp/gimpintl.h
#include gimp_tips.h
int
main (int argc, char **argv)
{
gint i;
INIT_LOCALE (gimp);
printf (gimp-tips\n);
for (i = 0; i n_tips; i++)
{
printf ( tip\n%s\n /tip\n, tips[i]);
}
printf (/gimp-tips\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
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
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
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
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
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.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: 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
Hi, Carol Spears [EMAIL PROTECTED] writes: It seems that all any decent site would need would be this: ?xml version=1.0? gimp-tips tip tip-number 0 /tip-number This is the first trip. /tip tip tip-number 1 /tip-number This is the second trip and it has bbold/b text. /tip tip tip-number 2 /tip-number This is the last trip. Now, you are on your own. /tip /gimp-tips hmm, wouldn't it be nicer to use the following instead ? ?xml version=1.0? gimp-tips tip number=0 This is the first trip. /tip tip number=1 This is the second trip and it has bbold/b text. /tip tip number=2 This is the last trip. Now, you are on your own. /tip /gimp-tips 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
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 won't solve all problems here (I've not suggested to replace
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.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 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
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
Sven ... [EMAIL PROTECTED] (2001-10-07 at 1656.37 +0200): hmm, wouldn't it be nicer to use the following instead ? ?xml version=1.0? gimp-tips tip number=0 This is the first trip. /tip tip number=1 This is the second trip and it has bbold/b text. /tip tip number=2 This is the last trip. Now, you are on your own. /tip /gimp-tips 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
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
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 detected syntactically (that languages' translation is simply gone
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 changed, translators need to easily
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
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 better machine readable format also has the
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 than any other (well, the most obvious ones excluded). Ok, then
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
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
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 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
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 emmuch/em 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 emimage manipulation/em 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 graphic, 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
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: tip lang=deNiemals GIMP schließen/tip tip lang=enNever close the GIMP/tip 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
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 emmuch/em 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 emimage manipulation/em 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 graphic, 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
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
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
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 emmuch/em more expressive. That's an abuse of a tag. em is a stylistic tag from the HTML days, with XML text should be marked like: markuplt;em/markup is a stylistic tag. The actual rendering is up to the stylesheets or preferences of the user/developer. But yes: In theory you're right. 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 emimage manipulation/em 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, 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 emmuch/em more expressive. That's an abuse of a tag. em is a stylistic tag from the HTML days, with XML text should be marked like: markuplt;em/markup is a stylistic 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 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
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
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, em is HTMLism. There's no em in DocBook for example, it's emphasis there Though the look of em can be changed by an CSS stylesheet it is not exactly the same as emphasis... -- 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
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
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
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 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
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
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: tip lang=deNiemals GIMP schließen/tip tip lang=enNever close the GIMP/tip 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
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: tip lang=deNiemals GIMP schließen/tip tip lang=enNever close the GIMP/tip 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
