Re: [Gimp-developer] Preferences suggestions
mån 2003-03-03 klockan 19.57 skrev Raphaël Quinet: c. Why a dpi *AND* a Pixels/inch setting? The bottom set, with the Pixels/inch options menu should be enough. DPI should be part of the text header for this frame. Because you want to be able to set the default unit? I prefer millimeters instead of inches. The default here (US/metric) should probably be a function of the locale, as that information is already available in the locale. Reported now as http://bugzilla.gnome.org/show_bug.cgi?id=107497. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl moved into its own CVS module
fre 2003-02-28 klockan 18.28 skrev [EMAIL PROTECTED]: http://bugzilla.gnome.org/show_bug.cgi?id=79751 Oops, this is certainly not something you told me about ever. The bug activity log for this report (available as a link from the page) very clearly shows that [EMAIL PROTECTED] added a cc: to [EMAIL PROTECTED] for this bug report almost a year ago, 2002-04-24... ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP missing from Fifth Toe
Currently, the packages for the GNOME Fifth Toe release is being brought together at the http://5toe.lyrical.net/ site, where package maintainers can nominate their software for inclusion. Fifth Toe is, for those that don't know, a collection of nice additional software that works with GNOME. Fifth Toe is released seperately from the rest of GNOME. GIMP fits that category well, and has also previously been included in Fifth Toe. Is the omission of GIMP from Fifth Toe intended, or an accidental omission? Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP missing from Fifth Toe
sön 2003-02-02 klockan 19.49 skrev Sven Neumann: Christian Rose [EMAIL PROTECTED] writes: Currently, the packages for the GNOME Fifth Toe release is being brought together at the http://5toe.lyrical.net/ site, where package maintainers can nominate their software for inclusion. Fifth Toe is, for those that don't know, a collection of nice additional software that works with GNOME. Fifth Toe is released seperately from the rest of GNOME. GIMP fits that category well, and has also previously been included in Fifth Toe. I'm sorry but I don't understand the concept at all and the webpage is not really helpful in clearing things up. What exactly is Fifth Toe? You say it's a collection of software. Is it just a list of packages or is the software also distributed somehow? To the best of my knowledge and judging from previous Fifth Toe releases, it's a common release of independantly developed software. In other words, there will be a common release at some point with a common release announcement saying this is the GNOME Fifth Toe release and this is the list of software included in it, listing applications and their versions. I'm cc:ing Will LaShell in this mail, perhaps he can clarify. I personally believe GNOME Fifth Toe has traditionally been a way to release software that isn't currently part of the core desktop and can be released as part of that, but may still be interesting to users. The idea is to help users when they have installed a new desktop and wonder where's the more nice tools and applications for it. A sort of nice bag of extra goodies. It also helps distributors; instead of having to list thirtysomething individual pieces of software or parts of it and decide which pieces to use they can just conveniently say includes GNOME Fifth Toe and include an already predefined set of packages. But that's just my view of it. Hopefully Will can clear out the issues. The website also don't explain which version of GNOME / GTK+ this release is based on. If it is GTK+-2.x, we are probably out of the race since there is no stable GIMP release for this platform. Good point. I don't know what the exact qualifications for inclusion are, but it probably includes in some point being ported to GNOME/GTK+ 2.0 or 2.2. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] What's with the appended %s?
Recently many messages in gimp have been changed to append %s, like in this example: #: app/tools/transform_options.c:223 #, c-format msgid Keep Height %s The %s seems to be filled in with the return value of a call to gimp_get_mod_name_control (). What's the purpose of these changes to the translatable messages? Are the ordering of the %s, or the amount of whitespace used, supposed to change with the translations? If they aren't, perhaps moving these %s outside the gettext calls should be considered. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] regex
tor 2002-11-28 klockan 00.32 skrev David Weeks: Robin, I called you right the first time. David, please keep childish name-calling rants like this for yourself. Thanks. Kind regards, Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] questions about the cvs structure
mån 2002-11-18 klockan 14.09 skrev jay.yan: http://www.gimp.org/devel_cvs.html tells me that I can get the latest code from cvs server via: cvs -z3 co gimp and also it says: There are also several branches in the GIMP cvs tree: the main or HEAD branch is GIMP 1.3 (the development version). Then I tried cvs -z3 co -r gimp-1-3 gimp, of course I failed, it said: no such tag gimp-1-3 Yes, that's correct. There's no gimp-1-3 branch. As the page says, the HEAD branch is for GIMP 1.3 development. The HEAD branch is what you get if you just use cvs -z3 co gimp. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] anocvs get does not give latest revision ?
On 6 Jun 2002, Sven Neumann wrote:
After a complete gimp clean (find . -name gimp -exec rm {};)
on my machine and new cvs get -z3 it still gets the old version
of the file gimpunits.c. But only that file is old. Other files
like Changelog are up to date.
I think it's time to write [EMAIL PROTECTED] and ask if there is
something they can do about the poor quality of anoncvs.
The cvsmaster people already know about most problems with anoncvs and
have promised to improve the situation post-gnome2.0.
Christian
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dependancies (used to be xinput)
ons 2002-06-05 klockan 23.28 skrev Philip Brown: This is as good a point to ask as any; in following the latest incarnation of the crazy dep-chain I ran into a dead-end finding the mysterious 'fontconfig' (fontconfig is needed by pango is needed by gtk2 is needed by gimp). Anyone know where I can find such a thing? I thought that it sounded like it was probably part of pkgconfig (pkgconfig is needed by... etc) but it doesn't seem to be. seems that the latest version of pkgconfig is not compatible with the latest version of pango. Which is a really good reason to not do this sort of nonsense. Just use autoconfig like always, instead of this silly pkgconfig. It's too redhat, for a software tool that's supposed to be cross-UNIX compatible. Good conspiracy theory or troll, but the problem is that fontconfig has nothing to do with pkgconfig, so that puts your little offtopic rant at shame. fontconfig is designed by Keith Packard of XFree86 fame. There's a fontconfig tarball at http://keithp.com/~keithp/download/. Haven't tried it though. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistentlylicensed]
On Wed, 29 May 2002, David Neary wrote: Hmmm... This is bad, because this is not compatible with the GPL. So we must either stop distributing these files or distribute them in a separate package that is not GPL'ed. Why is giving credit to an author incompatible with the GPL? It's not the credit-giving (typically, authors usually credit themselves in the file header) but the requirement of prominent advertizing. I'm not a license guru, but I think the GPL explicitly forbids extra license requirements above those specified in the GPL itself. So if you want an advertizing clause, you have to use a modified version of the GPL or combine the code with a modified version of the GPL, thus non-GPL. In fact, when I now searched gnu.org, I found this: http://www.gnu.org/licenses/gpl-faq.html#TOCOrigBSD I see no reason why an advertising clause need cause an issue... could someone explain it to me? This is most likely not the proper list for general licensing discussions or questions. I'm sure there are better suited lists for that. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usage of mnemonics in GIMP 1.3
lör 2002-05-04 klockan 18.10 skrev Sven Neumann: * what will be the impact on the translations when we start using these? translations will break and need to be updated. However I don't see any particular problem here. Of course translators need to put some thoughts into the mnemonics they use in the translations and should try not to deviate too much from the original (english) mnemonics. I usually consider the mnemonics to be chosen so that they are easy to remember and access to be of much higher importance than any attempt to make them not deviate too much from their English equivalents. Often, the English characters are not even part of the translated word, so it's usually not particularily useful to use a strategy of not deviating too much, especially as this strategy may cause the mnemonic to clash with much better mnemonics where it's not even possible to use the English equivalent even if you would want to do so. For these reasons, I myself have long since given up any strategy to not deviate too much, and instead try to choose the mnemonics wisely. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
fre 2002-05-03 klockan 22.37 skrev Sven Neumann: - If you are a translator or would like to help with translations, check http://sven.gimp.org/1.2/i18n.html to see if your language needs work. Hmm, if you want to make sure that all translators get this info, then it perhaps should be sent to [EMAIL PROTECTED] too. Cheers, Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
Correct. My error. Sorry. Christian lör 2002-05-04 klockan 01.57 skrev Sven Neumann: Hmm, if you want to make sure that all translators get this info, then it perhaps should be sent to [EMAIL PROTECTED] too. IIRC, I've sent a mail announcing the 1.2.4 release to gnome-i18n list a few weeks ago. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Menus, keybinding et al, first draft
lör 2002-02-16 klockan 06.59 skrev Marco Lamberto: Zoom In + [Yes, changed, a bit more logical, no?] Zoom Out- If you have an US keyboard you'll notice that while the minus - is immediatly accessible, the plus + is obtained by pressing Shift + =. I think that +/= it's a faster keybinding for an US-keyboard layout user. What about of a bit nationalized keyboard layout, they should be selected through the Options menu and NOT by using the locale There's no reason that the default couldn't be selected using values from the locale. The locale will in most cases be reliable, and the users that use nonstandard keyboard layouts can probably live with having to change the default. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Message reorganization in gimp HEAD complete?
tis 2002-01-22 klockan 08.25 skrev Rebecca J. Walter: Is the message reorganization in gimp HEAD completed? There are quite a few changes, and I'd like to know if it's more safe to start translating these without too many expected radical changes coming. Nope. I'm not done yet. The problem is that I have a higher work load at the moment and cannot complete things as rapidly as I had hoped. How should we deal with this? There are a lot of problems in there that need to be fixed, but my time is more limited and will come somewhat haphazardly. I would suggest waiting a little longer at least. I will try to finish the files in app/gui as soon as I can. those are the main strings, right? Sure, no problem. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Message reorganization in gimp HEAD complete?
Is the message reorganization in gimp HEAD completed? There are quite a few changes, and I'd like to know if it's more safe to start translating these without too many expected radical changes coming. Before anyone reminds me I'd like to state that I know, and am fully aware of the fact that HEAD is under heavy development, but I'd like to update the HEAD translation again, just like before the announced message reorganization, and thus want to know if the announced message reorganization is complete, so that I don't shoot myself too much in the foot by translating gimp HEAD. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Head Translation Breakages
Rebecca J. Walter wrote: Just to warn everyone before translators start freaking out at Sven, I am proofreading all original strings in the head branch of GIMP CVS. I don't know how long this will take me. I will send out another mail when I am mostly done. While this should improve future GIMP texts, it will break all existing translations in HEAD. I am not touching stable, just head. My personal opinion is that this is just fine, as long as it is only in HEAD. So when translators next work on translations, don't blame mitch and sven for all the fuzzies. It should result in improvements and easier translations in the future. (Plus translating head is discouraged anyway). If anyone wants to whine about this, whine at me. Nothing to whine about, but you should probably also forward this information to [EMAIL PROTECTED], as not all translators read this list. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Head Translation Breakages
Christian Rose wrote: So when translators next work on translations, don't blame mitch and sven for all the fuzzies. It should result in improvements and easier translations in the future. (Plus translating head is discouraged anyway). If anyone wants to whine about this, whine at me. Nothing to whine about, but you should probably also forward this information to [EMAIL PROTECTED], as not all translators read this list. Also, I forgot to add, *thank you* for doing this work. Better English language certainly helps making the translation process easier, and the translations better in the end. 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
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: 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
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
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
[Gimp-developer] Re: GIMP Tip of the Day messages
Sven Neumann wrote: 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? No, as you say, a header file is probably the easiest solution, there is probably no need for XML as there are no attributes etc. Thanks for looking into this! 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: 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
[Gimp-developer] Re: Translating The GIMP
Sven Neumann wrote: It isn't up to you as the program maintainer to merge translations from STABLE to HEAD or something like that. Provide hints how translators might proceed, but please don't change contents of the files. I have always asked people not to touch po files in CVS HEAD at all. Until we change this rule, the po files are in the maintainers responsibility. I do not agree. Committing PO files to HEAD in any project is always risky business (large frequent changes im messages), and time for translating is always better spent in the stable branch, if there is one. HEAD is secondary at best, and translators should know what they are doing if they touch the HEAD branch. That I agree on. But I think it's stupid to entirely forbid committing translations to the HEAD branch, if the translators know what they are doing. Why? Because of testing. Testing translations is as needed as testing code - translations for new/changed messages in the HEAD branch might be wrong, and we'd like to spot and fix those before any release. Also, having a complete or near complete translation in HEAD helps finding i18n bugs - If I know my translation is complete, a message that appears in English almost certainly indicates that a developer forgot to gettextify a message, and those bugs can be reported/patches made/fixed before a release. This is not an uncommon situation for many applications. GTK+ has/had a similar policy for HEAD - Translators were strongly encouraged not to translate HEAD. I chose to ignore that and committed an updated complete UTF-8 translation for HEAD anyway (stable is of course still my top priority). I knew about the danger of translating a rapidly moving target, and I decided that I still wanted to try it. What happened? A month later a GTK+ developer thanks me for the translation because it gave him something to test UTF-8 cleanliness in new GTK+ code with. A month later the once complete HEAD translation is at only 50% because of added/changed messages, but I knew that this would happen at some time, before I started working on the HEAD translation. But the net result is still that this GTK+ HEAD translation helped others, including a GTK+ developer. So, please, advise translators to put their efforts in the stable branch, but please don't forbid those translators that feel that they can afford it to also commit translations in HEAD. PO files are translators land. Maintainers don't have the right to convert them into another charset. Leave these files alone, please. as said above, I consider po files in gimp CVS HEAD maintainers land. Translators have been asked not to enter this area multiple times. PO files are translators' land. They maintain them. Don't touch them. The translators know the language, developers in most cases don't. Translators know what charset is best suited for the locale, and works with the translation tools they use, developers don't. If you want to maintain a translation, you are free to translate yourself¹. ;) I myself would probably convert the sv.po in Gimp HEAD to UTF-8, like in GTK+, if I was kindly asked to, and it was recommended, but I still don't want others to touch the PO file. I think I could live with having to run iconv back and forward every time I touch the file, maybe I could also live with the different charset breaking the translation memory I use. But please let me still maintain the file, and don't touch it! For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. You've just described the GNOME Translation Project. Christian ¹ I know you are translating de.po. But that's only 1/27 of the translations. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
R.I.P. Deaddog wrote: I myself would probably convert the sv.po in Gimp HEAD to UTF-8, like in GTK+, if I was kindly asked to, and it was recommended, but I still don't want others to touch the PO file. I think I could live with having to run iconv back and forward every time I touch the file, maybe I could also live with the different charset breaking the translation memory I use. But please let me still maintain the file, and don't touch it! There are two kind of people that commit po files into HEAD branch; one kind is so stupid that they can't even distinguish between HEAD and stable branch, and another kind knows very well what they're doing. So how about a method distinguishing these two kind of people? I don't think it has anything to do with stupidity. It's probably just that people don't know about branches and/or how to check out different branches. Every other project using its own system with branches probably doesn't help either. I guess we've all been there, not knowing how to properly use branches, unless we were born with knowledge about CVS. I have no good solution for solving this. I think that information helps though. Every translation request mail to gnome-i18n should contain information about what branch(es) to use IMHO, and if the maintainer is really worried that translations will go to the wrong branch, including instructions in the mail on how to check out the correct branch(es) probably doesn't hurt. Also, some projects use files named TRANSLATORS_READ_THIS or similar in the po directories in the wrong branch, with information about the right branch to use. It's buttugly, but effective, I think. Also, once the maintainer sees a translation go to the wrong branch, replying to the translator as soon as possible and ask if it wasn't really meant for the stable branch probably also helps. Again, I don't think this solves this problem completely, and I also suspect GIMP in particular does many of these things already, but I think it helps. For example, send a piece of email to committer/last translator. If they do reply and acknowledge/reject the overwriting of HEAD branch po files, then one knows they are still actively maintaining the file; otherwise one can safely assume the file is not actively maintained, and can be overwritten freely. Agreed, but it should be done soon after the commit. I don't think reverting a translation update because the translator happens to be away from his mail for a week some time during the summer is a good thing. But yes, I agree, Communication is King. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Sven Neumann wrote: I have always asked people not to touch po files in CVS HEAD at all. Until we change this rule, the po files are in the maintainers responsibility. I do not agree. Committing PO files to HEAD in any project is always risky business (large frequent changes im messages), and time for translating is always better spent in the stable branch, if there is one. HEAD is secondary at best, and translators should know what they are doing if they touch the HEAD branch. That I agree on. But I think it's stupid to entirely forbid committing translations to the HEAD branch, if the translators know what they are doing. Why? Because of testing. I didn't forbid it, I only tried to encourage people to concentrate on the stable branch. Ok, that sounds sensible. I misinterpreted it, sorry. Now I want to weaken this policy since we are approaching a developers release. I had the idea of helping translators by bringing the translations in the unstable tree uptodate with the stable tree so they have something to start with. I think I am now convinced that I shouldn't do this. Ok, good. The problem is however that some of our translators don't have commit access and have been promised that their translations will be added to the unstable tree when the time has come. Well, the time has come, so what am I supposed to do? Ask them. :) Ask them if they want you to do this for their translation. I think you should ask this individually, for every translator, because the responses and wishes might be entirely different. Translators know what charset is best suited for the locale, and works with the translation tools they use, developers don't. well, I do know that we need UTF-8 encoded strings for GIMP since we use GTK+-2.0. IMO the best solution is to enforce UTF-8 encoding for our po files just like GTK+ does. I'll try to stay out of the technical merits. I've been wrong before. What matters to me is that I get to decide what encoding to use in my translation. I'll be happy to take advise and recommendations, and would probably switch to UTF-8 if it helps (I'll take your word that is does), but I want the final say on what encoding to use in my translation. I believe most other translators also want this, since a charset change often breaks existing translation tools and procedures. Some people have said that gettext already supports runtime conversion. Even if this introduces a performerance penalty, I'd argue that any other decision a translator makes on how to localize the application into his locale, *also* effects the look and feel of the application. I don't see how an informed decision on charset, that possibly affects performerance, would be very much different. It affects the look/feel/performerance of the application in that locale. All this is of course given that runtime conversion works, and as I said, I've been wrong before. But I'd really like this possibility to get investigated. Forcing is bad. Encouraging is good. If you have the possibility to just encourage instead of force, I think you should do that. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Translation teams and the GTP (was Re: Translating The GIMP)
This is a rather separate thread, so I'm replying to it seperately. Sven Neumann wrote: For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. You've just described the GNOME Translation Project. hmm, not all of our translators are part of the GNOME translation project and GIMP != GNOME. For that reason, I'd like to maintain a list of language maintainers in the GIMP source tree. If the GNOME translation project wants to take this job and thinks such a list is a waste of time, this is something we can and should consider, but it needs to be discussed. I cannot speak for all of the GNOME Translation Project (GTP; http://developer.gnome.org/projects/gtp/). However, what you described is confusingly similar to the GTP. Yes, GIMP != GNOME, but noone has to use GNOME to be a member in the GTP, nor do they have to contribute anything to GNOME at all, except the GIMP translation in this case if they want to do that. Also, GIMP uses GNOME CVS, and the GTP is basically just a collection of volunteering translators, some of them with GNOME CVS access, divided into ~40 language teams. Each team has a team coordinator that should keep track of who does what, and most teams also have at least one person with GNOME CVS access (often the coordinator), that can commit translations for their language team. So I don't see many reasons not to use this existing setup. Also, if you have trouble getting much else done besides committing translations that you recieve, I'd suggest also actively encouraging existing GIMP translators to try to submit their translations to their corresponding GNOME translation team so it can be committed that way, and only send it to you if that doesn't work. The people in the GNOME translation teams with CVS access do after all have CVS access because they should commit translations for their language. That's what they are supposed to do. :) I know there are different opinions on this, we've had an extensive debate on this in Galeon (hi Yanko! :) but IMHO this is policy that is suitable in many cases. It reduces workload for developers, and also encourages translators of the same language to work together and communicate, which in turn usually gives better translations. IMHO of course. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
