Re: English translations (was Re: Gimp Wishes)
On Thu, Mar 30, 2000 at 08:49:16PM +0200, Stanislav Brabec wrote: > -- Other problem is about translating some splitted messages to many > languages (gender problems etc.) Example with Czech: > Free = Volny (Selection) > Free = Volna (Curve) > Brush = Stetec (Brush as tool) > Brush = Stopa (Brush as stroke) Later in the thread (on Apr 03, 05:10PM +0100), Nick Lamb replied with: > Anyway, expecting everyone to support translation catalogs just so > that you can hack around bizarre grammatical features in some > languages is a bit much. You call adjectives and articles with gender "bizzare grammatical features"? I may not be fluent in any language but en_GEEK, but I know that such use of gender in many other languages is in no way bizzare or obscure, and that getting it wrong is one of the fastest ways to get yourself flagged as a careless foreigner who does not have enough respect for the language to speak it properly. And you expect nouns and verbs which happen to be spelled the same way in English to be so in other languages? They're entirely different parts of speech! Just because we have fallen into a habit of verbing nouns dosen't mean that other languages work the same way. Switching from anglo-centric to Linux-centric, I don't know what the status of catalouge support on other platforms is at the moment, but it seems to have quite wide support under Linux these days, so installing an English catalouge seems like a reasonable option. And if you should choose to ./configure --disable-nls, well, just think of "Free#m" as another spelling of "colour". If it wouldn't kill the coder's will to do documentation entirely, I'd advocate all strings be written in some less-ambigious language like Lojban. But I think that'll have to wait until the majority of the developers are members of the logical language group ;) Love, Kevin -- Kevin Turner <[EMAIL PROTECTED]> | OpenPGP encryption welcome here
Re: English translations (was Re: Gimp Wishes)
At 05:10 PM 4/3/00 +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: >On Mon, Apr 03, 2000 at 02:53:42PM -, Karl Heinz Kremer wrote: >> Why should English be treated differently than any other language? >> Let's just add an English catalog to the default installation and >> the user will not see any difference. > >There is already a catalog (en_GB) for British users of English who >prefer to keep the OED spellings, rather than surrender to the >alternate (but more common) American US spellings. But perhaps not as relatively common as you might think. The world is full of ex-British colonies that still use English closer to British English than American English. Australia, New Zealand, South Africa...I don't know about Canada. America would be the most significant ex-British colony that diverged. >I don't think any of us take it seriously (I often don't remember to >set up i18n for ages after building a new system) because we've >come to accept that something very *like* English will eventually >be written by everyone, no matter how they spell colour, or what >they call petrol and nappies. (*) This is a shame, but I guess it's to be expected, particularly where development is done by volunteers with limited time. Although big companies like MS provide localised (* Note: Australian spelling. I gather we are on our own in standardising all -ise and -ize words to -ise) English spelling dictionaries, including Australian English, they don't seem to localise their help, menus etc. Roll on, cultural imperialism. >Anyway, expecting everyone to support translation catalogs just so >that you can hack around bizarre grammatical features in some >languages is a bit much. Instead try re-writing the code if you >can, so that it uses separate phrases in each case. Makes perfect sense. >(*) Even in Japan, convergence is happening, although since it's >in a foreign alphabet that's not as helpful as it might be. I think the convergence is more superficial than it seems. Words are often borrowed, but the pronunciations are warped beyond recognition; the words are abbreviated at places that seem natural in Japanese but make them unrecognisable in English; the words are given different meanings; and so on. Many centuries of English's exposure to French has done very little to make the languages similar, in spite of many borrowings (take a word like "lingerie", for example). Regards, Ian
Re: Gimp Wishes (efficient trivial wishes)
Stanislav Brabec wrote: > There are more solutions: > -- Make little wider default window size (or tool icons). > -- Decrease horizontal space between menus or default to smaller font >in main menus (maybe in default gimprc). > -- Default to "old-style look" (brush, color & pattern on left). > > Better solution are welcome... I don't know if it's 'better,' but two things I can think of offhand are (1) change the font to something smaller or (2) add another tool (what: I dunno) so that the toolbox can be a 4x7 rectangle. I don't know if 4x is enough space, but 7x should be and it would narrow the color and brush/gradient/pattern boxes. $0.02, Christopher
JPEG correction (was Re: Gimp Wishes)
(although this is as a reply to Marc's post I only noticed it in the more recent replies, sorry if that screws up threading for anyone) On Sat, Apr 01, 2000 at 07:46:03PM +0200, Marc Lehmann wrote: > I don't think this really is so much of a problem. Saving a jpeg in the same > quality as it was originally saved will do no good to your quality. The only > thinvg it will ensure is that the file-size will be similar. This isn't true, IJG documentation and home made tests show that, for what little it is worth JPEG(75) -> JPEG(75) -> JPEG(75) applied to any set or subset of image tiles can do much LESS damage than e.g. JPEG(75) -> JPEG(85) -> JPEG(75) -- even though the latter results in the same size files, give or take. This isn't guaranteed, but will usually work if you keep everything the same (codec, compiler, libraries, CPU, direction of the wind...). In any case it never does any harm. In fact, this improvement can be enough for the difference between "obviously re-edited JPEG" and a seamless fix to an image when you've lost the original. The only trouble with this fact is that there's no usable mechanism for divining which settings were used to compress the image, or even whether the IJG codec was used at all. IMHO that's for the best. I should not need to care which encoder was used to use the image. Nick.
Re: Gimp Wishes (efficient trivial wishes)
On Fri, Mar 31, 2000 at 06:00:08PM +0200, [EMAIL PROTECTED] wrote: > On 30 Mar, Stanislav Brabec wrote: > > > I18n wishes: > > > > -- Please do anything with the fact, that main panel menu with default > >GTK theme can contain exactly 15 letters. Too few for three items > > inmost languages. > > What exactly would you suggest? That's actually a matter for the > translators, not for the developers, as we don't know all the > languages around the world. :) > Yes, it's for translators, but translators are stressed to translate all "File Xtns Help" to 15 letters. More letters looks ugly or makes Help unusable. (see "LANG=fr gimp") There are more solutions: -- Make little wider default window size (or tool icons). -- Decrease horizontal space between menus or default to smaller font in main menus (maybe in default gimprc). -- Default to "old-style look" (brush, color & pattern on left). Better solution are welcome... -- Stanislav Brabec
Re: Gimp Wishes (i18n and jpeg)
On Sat, Apr 01, 2000 at 07:46:03PM +0200, Marc Lehmann wrote:
> That could be done before 1.2, with added stress for the translators, but...
> I think using optional(!) tags (which will be more verbose) will be even more
> useful: Not much added strain on the programmer, not much strain on
> translators (we need one more translator for the en mapping).
On Mon Apr 3 15:06:25 2000 Daniel Egger wrote:
>> Tell it the programmers; they will have to add "prifixes" to make the
>> strings different; e.g.:
> That's not meant to be serious, is it? It would be really a
> pain-in-the-ass to maintain this, even in the most simple case.
I am thinking about less stressing version:
Little change in gettext (or some post-code), creating two catalogs:
gimp.pot and gimpR.pot.
gimp.pot will not be affected by any post/prefix.
gimpR.pot will contain only post/prefixed messages in full version.
So, gimp.pot will be translated in standard way, gimpR.pot will stay
untranslated unless one actually need difference between strings.
Both can be merged during compilation.
This affects:
-- gettexting mechanism in code (we need two lookups - with and without
post/prefix).
-- needs extra code in addition to standard "gettextize".
-- definition of __ in header (or optionally redefinition of _ - see lower)
Don't affects:
-- Already existing translation.
For example:
code.c:
__("selection~Free")
gimp.pot
#: code.c:111
msgid "Free"
gimpR.pot
#: code.c:111
msgid "selection~Free"
There are two ways to create pre/postfixes: "preventive" (do it for
all possible problematic strings) and "on demand" (if any translation
in any language looks ugly, one (the translator) will do it).
I see also one chance: Automatic prefix generation on c-filename basis.
It's sufficient for most cases (but not all), and requires only re-defining
of _ macro. __ macro (and prefix) will be used explicitly only for places, where
per-filename prefix is not sufficient.
For example:
code.c:
_("Free")
gimp.pot
#: code.c:111
msgid "Free"
gimpR.pot
#: code.c:111
msgid "code.c~Free"
>
> > -- Jpeg: There is a problem to guess compression and some save options
> >from jpeg data. So we load image compressed in 98% quality,
> >and consequent Save will default to 75% quality.
>
> I don't think this really is so much of a problem. Saving a jpeg in the same
> quality as it was originally saved will do no good to your quality. The only
> thinvg it will ensure is that the file-size will be similar.
>
Saving in higher quality means vaste of disk space. Saving with less quality
will cause loss of quality. So the best is to save certain jpeg in the same
quality all times.
--
Stanislav Brabec
English translations (was Re: Gimp Wishes)
On Mon, Apr 03, 2000 at 02:53:42PM -, Karl Heinz Kremer wrote: > Why should English be treated differently than any other language? > Let's just add an English catalog to the default installation and > the user will not see any difference. There is already a catalog (en_GB) for British users of English who prefer to keep the OED spellings, rather than surrender to the alternate (but more common) American US spellings. I don't think any of us take it seriously (I often don't remember to set up i18n for ages after building a new system) because we've come to accept that something very *like* English will eventually be written by everyone, no matter how they spell colour, or what they call petrol and nappies. (*) Anyway, expecting everyone to support translation catalogs just so that you can hack around bizarre grammatical features in some languages is a bit much. Instead try re-writing the code if you can, so that it uses separate phrases in each case. (*) Even in Japan, convergence is happening, although since it's in a foreign alphabet that's not as helpful as it might be. Nick.
Re: [gimp-devel] Re: Gimp Wishes (efficient trivial wishes)
Karl Heinz Kremer ([EMAIL PROTECTED]) wrote: > [EMAIL PROTECTED] said: > > Please note that adding "tags" to the messages will mean that GIMP > > isn't usable any more without catalogs which is not very sensible > > IMHO. I'd rather refine the messages to have more variance in the > > texts... > > Why should English be treated differently than any other language? > Let's just add an English catalog to the default installation and > the user will not see any difference. Until he disables nls-support. Some users want this. And then english is better than some crude tagged semi-english. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Gimp Wishes (efficient trivial wishes)
[EMAIL PROTECTED] said: > On 1 Apr, Marc Lehmann wrote: > > > I think using optional(!) tags (which will be more verbose) will be > > even more useful: Not much added strain on the programmer, not much > > strain on translators (we need one more translator for the en > > mapping). > > Please note that adding "tags" to the messages will mean that GIMP > isn't usable any more without catalogs which is not very sensible > IMHO. I'd rather refine the messages to have more variance in the > texts... Why should English be treated differently than any other language? Let's just add an English catalog to the default installation and the user will not see any difference. If we want people to use the localized versions of Gimp withoug laughing at us we better do a good job in making sure that we can display messages that make sense in any language. Daniel, I guess you are German. Have you ever encountered software that was localized to the German locale and still displayed messages that sounded more like English even though all the words were in German? I've delt with internationalization and localization for several years now (working for a US based company). I don't think that I've seen it all, but I have certainly seen a lot of really bad attempts to localize software. If we can not do it right, we should not even try. ... just my 2 (not localized) cents, Karl Heinz
Re: Gimp Wishes (efficient trivial wishes)
On 1 Apr, Marc Lehmann wrote: > I think using optional(!) tags (which will be more verbose) will be > even more useful: Not much added strain on the programmer, not much > strain on translators (we need one more translator for the en > mapping). Please note that adding "tags" to the messages will mean that GIMP isn't usable any more without catalogs which is not very sensible IMHO. I'd rather refine the messages to have more variance in the texts... -- Servus, Daniel
Re: 1.1.19-installation fails
On Sun, 2 Apr 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote: [...] > Unless somebody comes up with a better solution, I'll try the following > (Without any understanding of what I do): > > if @MSGFMT@ is != "" and != "no" then just assume MSGFMT is valid, and that > msgmerge is somewhere in the path. Otherwise, just suppose @MSGFMT@ a > msgmerge are not available. Ahhh... Now I think that I understand why gimp-1.1.19 cannot be built unless you disable Perl (see bug #8148). The problem is that if you find "msgfmt", you also assume that "msgmerge" can be found somewhere in the path. Unfortunately, many systems have msgfmt but do not have msgmerge. This is the default under Solaris (at least for Solaris 2.5.1, 2.6 and Solaris 7) and under SuSE Linux (unless you install the dev rpm that contains msgmerge). I think that msgfmt is more or less standard, but msgmerge is not. You only get the latter with GNU gettext, not with the other versions of gettext. Please add separate tests for msgfmt and for msgmerge. This would probably solve bug #8148. -Raphael
