On Mon, 2008-06-16 at 15:18 -0500, Shaun McCance wrote:
> On Mon, 2008-06-16 at 20:48 +0100, Alan Cox wrote:
> > > Well, as I said, in this case:
> > >
> > > gtk_label_new(_(some_string));
> > >
> > > The output of gettext can (and often will) be UTF-8,
> > > so gtk_label_new is going to receive
On Mon, 2008-06-16 at 19:51 +0100, Alan Cox wrote:
> > All of that means that there are no run-time problems.
> > The only actual concern is whether compilers will choke
> > on UTF-8 source files. Alan says that, according to the
> > standard, a compiler would be perfectly right to choke.
> > I be
On Mon, 2008-06-16 at 20:48 +0100, Alan Cox wrote:
> > Well, as I said, in this case:
> >
> > gtk_label_new(_(some_string));
> >
> > The output of gettext can (and often will) be UTF-8,
> > so gtk_label_new is going to receive UTF-8 whether
> > some_string is ASCII or not. If it's not UTF-8-safe
> > They work perfectly when you pass them UTF-8 data no matter what your
> > locale.
>
> Just to back this up:
>
> http://library.gnome.org/devel/gtk/stable/gtk-question-index.html#id2776084
Cool - so for anything which doesn't touch the C library directly you can
write _("\xABCD") type stuff
> Well, as I said, in this case:
>
> gtk_label_new(_(some_string));
>
> The output of gettext can (and often will) be UTF-8,
> so gtk_label_new is going to receive UTF-8 whether
> some_string is ASCII or not. If it's not UTF-8-safe,
> we're pretty much screwed already.
No no no
The output of _
On Mon, 2008-06-16 at 19:41 +0100, Iain * wrote:
> On Mon, Jun 16, 2008 at 7:11 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > On Mon, 16 Jun 2008 17:48:31 +0100
> > "Iain *" <[EMAIL PROTECTED]> wrote:
> >
> >> On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
> >> > In LANG=C you
On Mon, 2008-06-16 at 19:51 +0100, Alan Cox wrote:
> > All of that means that there are no run-time problems.
> > The only actual concern is whether compilers will choke
> > on UTF-8 source files. Alan says that, according to the
> > standard, a compiler would be perfectly right to choke.
> > I be
Am Montag, den 16.06.2008, 18:59 +0200 schrieb Dave Neary:
> Iain * wrote:
> > On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
> >> In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that
> >> point depends if gtk_label_new ever calls a single C library funct
> All of that means that there are no run-time problems.
> The only actual concern is whether compilers will choke
> on UTF-8 source files. Alan says that, according to the
> standard, a compiler would be perfectly right to choke.
> I believe him. I also don't care.
I don't think that one is a s
On Mon, Jun 16, 2008 at 7:11 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Jun 2008 17:48:31 +0100
> "Iain *" <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
>> > In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that
>
On Mon, 16 Jun 2008 17:48:31 +0100
"Iain *" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that
> > point depends if gtk_label_new ever calls a single C library function
> >
On Mon, 2008-06-16 at 18:59 +0200, Dave Neary wrote:
> Iain * wrote:
> > On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
> >> In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that
> >> point depends if gtk_label_new ever calls a single C library function
>
Iain * wrote:
> On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
>> In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that
>> point depends if gtk_label_new ever calls a single C library function
>> that is locale dependant (eg strcasecmp).
>
> All of GTK is
On Mon, Jun 16, 2008 at 11:20 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
> In LANG=C you call gtk_label_new with UTF-8 strings. What happens at that
> point depends if gtk_label_new ever calls a single C library function
> that is locale dependant (eg strcasecmp).
All of GTK is utf-8 compatible.
This
On Sun, 2008-06-15 at 01:24 +0200, Patryk Zawadzki wrote:
> On Sat, Jun 14, 2008 at 1:14 PM, Alexander Jones <[EMAIL PROTECTED]> wrote:
> > 2008/6/14 Alan Cox <[EMAIL PROTECTED]>:
> >> Note; I am all for the US locale using pretty quotes. I'm just strongly
> >> opposed to doing it against the speci
> > (you could extract the translations from the converted file to
> > save having to mend all the translations but that might actually be long
> > term worse)
>
> This would result in a thousand .c.in files or a large header .h.in
> file with all the strings ;)
Not really. You just generate a te
On Mon, Jun 16, 2008 at 12:24 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> BTW: I realised last night there is another way to tackle this which lets
> you turn the problem on its head
>
> Given smart quotes directly in code are not valid C and that you need to
> distinguish different quotes so can't d
BTW: I realised last night there is another way to tackle this which lets
you turn the problem on its head
Given smart quotes directly in code are not valid C and that you need to
distinguish different quotes so can't do a perl 1 liner turn the problem
the other way up
Source - with smart quotes
On Sun, 15 Jun 2008 00:32:05 +0100
> gtk_label_new (_("this is a string with "" in it"));
Well firstly it is no longer C. You should be using \2xx\0xx or \xblah
encoding but that is a trivial side item to fix. Assuming you fix that it
obviously compiles and probably comes out ok in a .po file.
In
Le samedi 14 juin 2008 à 01:06 +0100, Bastien Nocera a écrit :
> On Fri, 2008-06-13 at 18:01 -0400, Dan Winship wrote:
> > Alan Cox wrote:
> > > GTK/Glib are not the biggest problem here. You also use C library
> > > functions in Gnome applications. Glib/Gtk+ works with the C library in C
> > > loc
On Sat, Jun 14, 2008 at 7:40 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sat, 14 Jun 2008 18:42:24 +0100
> "Iain *" <[EMAIL PROTECTED]> wrote:
>
>> On Sat, Jun 14, 2008 at 3:35 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
>>
>> > Thats because you have your fingers in your ears and don't want to
>> > l
On Sat, Jun 14, 2008 at 1:14 PM, Alexander Jones <[EMAIL PROTECTED]> wrote:
> 2008/6/14 Alan Cox <[EMAIL PROTECTED]>:
>> Note; I am all for the US locale using pretty quotes. I'm just strongly
>> opposed to doing it against the specifications and praying it works out.
>> Particularly when its proba
On Sat, 14 Jun 2008 18:42:24 +0100
"Iain *" <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 14, 2008 at 3:35 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > Thats because you have your fingers in your ears and don't want to
> > listen. Consider a career in politics instead.
>
> Well, no, you have brought
On Sat, Jun 14, 2008 at 3:35 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> Thats because you have your fingers in your ears and don't want to
> listen. Consider a career in politics instead.
Well, no, you have brought up irrelevant points (to the question at
hand) and straw manned any rebuttal of the
> Sarcasm aside, if people are using Shift-JIS/KOI8R/RU in translations,
> those strings WILL get fed into UTF-8 string functions and stuff will
> break. We use UTF-8 here, in GNOME-land, right?
If the gnome libraries have built in UTF-8 assumptions yes. But the rest
of the system will work just f
2008/6/14 Alan Cox <[EMAIL PROTECTED]>:
> I don't know if the use of KOI8R/RU and shift-jis is still "legitimate".
> I guess you would have to ask the users. I also don't know what the
> situation is for usage patterns on non-Linux systems. Sun have always been
> on the ball with unicode but some o
On Fri, Jun 13, 2008 at 8:25 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
>
>> Surely as programmers we can be trusted to know the difference between
>> the cases where a string is destined for the UI and where it is
>> destined for something that is non-UTF8 compatible?
>
> You have an encylopædic know
> > Are there actually legitimate reasons for anyone to ever use a non-UTF-8
> > locale these days?
>
> Other than legacy, and wanting to find bugs in programs? Probably not...
> Maybe somebody should break the compatibility view and make the C locale
> UTF-8.
Well you can certainly submit a prop
On Sat, 14 Jun 2008 01:43:05 +0100
"Alexander Jones" <[EMAIL PROTECTED]> wrote:
> Alan, you seem to be missing the point.
No I'm afraid you are the one who is missing the point here:
> The only places where I am suggesting replacing "" with "" are in existing
> gettext calls, which *are* UTF-8 w
On Sat, 14 Jun 2008 01:44:09 +0100
"Alexander Jones" <[EMAIL PROTECTED]> wrote:
> So how do we go about coming up with an official position for this? If
> I start cooking patches here and there I don't want to have to make
> the same argument with every maintainer... :)
It seems the standards doc
On Fri, 13 Jun 2008 18:01:22 -0400
Dan Winship <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > GTK/Glib are not the biggest problem here. You also use C library
> > functions in Gnome applications. Glib/Gtk+ works with the C library in C
> > locale simply because ASCII is a subset of UTF-8. That
So how do we go about coming up with an official position for this? If
I start cooking patches here and there I don't want to have to make
the same argument with every maintainer... :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http:
Alan, you seem to be missing the point. The only places where I am
suggesting replacing "" with "" are in existing gettext calls, which
*are* UTF-8 whether they need to be or not, and are always used with
UTF-8 string functions.
The issue is whether the compiler will bork when it sees bytes with
M
On Fri, 2008-06-13 at 18:01 -0400, Dan Winship wrote:
> Alan Cox wrote:
> > GTK/Glib are not the biggest problem here. You also use C library
> > functions in Gnome applications. Glib/Gtk+ works with the C library in C
> > locale simply because ASCII is a subset of UTF-8. That ceases to work the
>
On Fri, 13 Jun 2008 19:41:15 +0100
"Iain *" <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 13, 2008 at 4:12 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > What about printing to files ? An "nm" also rather suggests that gnome
> > apps do use printf and fprintf somewhat and many of the other functions
>
On Fri, Jun 13, 2008 at 4:12 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> What about printing to files ? An "nm" also rather suggests that gnome
> apps do use printf and fprintf somewhat and many of the other functions
> mentioned. syslog() is another that is used.
I don't know what your use cases a
> Since you don't know whether the result of _("foo") will be strict ASCII,
> you must always treat it as if it were not. GLib/GTK+ *requires* UTF-8
> strings for all (most?) of its string handling functions...
GTK/Glib are not the biggest problem here. You also use C library
functions in Gnome ap
2008-06-13 klockan 16:44 skrev Alan Cox:
> If your string is untranslated then _("foo") -> "foo". If your locale is
> not unicode then this places utf8 symbols into non-utf8 locales.
Since you don't know whether the result of _("foo") will be strict ASCII,
you must always treat it as if it were no
> Some people are worried about string functions breaking. I really
> don't see how this is the case, seeing as we're doing g_some_function
> (_("Some ASCII string")) which is replaced with a UTF-8 string at
> runtime anyway.
>
> Does anyone have any actual proof of UTF-8 in our translatable strin
Hi list
To reignite this discussion now that I've finished my exams...
I posted this on Simos' blog a while back, but the discussion there
had died off it seems, so I'll repost here.
UTF-8 is designed so that subsequences are unambiguous. You won't get
a byte less than 0x80 in any part of a mult
On Wed, 14 May 2008 04:17:09 -0400
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
> As James says on Simos's blog post, all strings inside GTK apps are
> defined to be UTF-8 regardless of locale. GLib and GTK will convert on
> the fly to locale encoding if they print to a terminal.
gtk may do, but
As James says on Simos's blog post, all strings inside GTK apps are
defined to be UTF-8 regardless of locale. GLib and GTK will convert on
the fly to locale encoding if they print to a terminal. So there
should be no issue with "C" locale other than possibly some odd
escaping. (Which could in theor
> "Shaun" == Shaun McCance <[EMAIL PROTECTED]> writes:
Shaun> But plenty of people have been putting UTF-8 string
Shaun> literals in C code for some time, seemingly without
Shaun> problems.
Yes, it works fine with gcc. You have to make sure you set the
execution character set properly, but t
On Thu, 2008-05-15 at 11:19 -0500, Federico Mena Quintero wrote:
> On Tue, 2008-05-13 at 12:20 -0500, Shaun McCance wrote:
>
> > If I have to use the en translation, then I have to put
> > this string in the source code:
> >
> > The file "%s" could not be found.
> >
> > Then I have to run 'in
> utf-8 encoded litteral DO work in C, without glitch.
Assuming the functions in any library (including the C library) you
pass such UTF-8 encoded strings to expects them to be UTF-8...
And UTF-8-encoded wide string literals hardly work correctly unless
you explicitly tell the compiler that the c
On Thu, 2008-05-15 at 11:19 -0500, Federico Mena Quintero wrote:
> C is hard. Unicode didn't exist in the 1970s. Get over it.
>
> If you want UTF-8 strings in your source code without escaping
> non-ASCII
> chars, use C# or another modern language which supports that.
utf-8 encoded litteral DO
O/H Shaun McCance έγραψε:
> On Tue, 2008-05-13 at 17:36 +0100, Alan Cox wrote:
>
>>> Honestly, other than being pedantic, I don't see the
>>> problem with UTF-8 in the C locale. Does it cause
>>> any *actual* problems? I've never once gotten a bug
>>> report against g-d-u about this.
>>>
On Tue, 2008-05-13 at 12:20 -0500, Shaun McCance wrote:
> If I have to use the en translation, then I have to put
> this string in the source code:
>
> The file "%s" could not be found.
>
> Then I have to run 'intltool-update en', open en.po,
> and add the translation. That's more steps, none
O/H Thomas Thurman έγραψε:
> Ysgrifennodd Alan Cox <[EMAIL PROTECTED]>:
>
>> Sort order, comparisons, printing, string lengths when using locale aware
>> functions, and no doubt a few more that for the moment have escaped me.
>>
>> Use the tools to spec and you get reliable predictable results,
Ysgrifennodd Alan Cox <[EMAIL PROTECTED]>:
> Sort order, comparisons, printing, string lengths when using locale aware
> functions, and no doubt a few more that for the moment have escaped me.
>
> Use the tools to spec and you get reliable predictable results, do
> otherwise and it all gets sloppy
O/H BJörn Lindqvist έγραψε:
> On Tue, May 13, 2008 at 2:19 PM, Christian Neumair <[EMAIL PROTECTED]> wrote:
>
>> Alex Jones proposed [1] to change the quotation marks in Nautilus
>> strings from the ASCII representation "..." to the unicode variant
>> "...".
>>
>> I think the proposed quotat
On 2008-05-13, 14:45 GMT, Pat Suwalski wrote:
> My objection may seem silly, but since there is no way to type it on any
> keyboard out there, that's a bit of a hindrance. Short of using the
> character map and searching, one has to resolve to using "smart
> substitution" editors like OpenOffice
On Tue, May 13, 2008 at 2:19 PM, Christian Neumair <[EMAIL PROTECTED]> wrote:
> Alex Jones proposed [1] to change the quotation marks in Nautilus
> strings from the ASCII representation "..." to the unicode variant
> "...".
>
> I think the proposed quotation marks are aesthetically more pleasin
Wouter Bolsterlee wrote on 13/05/08 17:19:
>
> 2008-05-13 klockan 16:19 skrev Christian Neumair:
>...
>> I hereby propose to establish a GNOME policy of using “...” for
>> quotations. Comments, objections?
There is a test case for this: Epiphany uses typographical quote marks
throughout its inte
As Shaun points out, it gets a little convoluted.
Alan Cox wrote:
> Which rules does Canada follow for the ending of a sentence with quoted
> text ?
> "quoted text."
> or
> "quoted text".
>
> That might need a locale anyway
Assuming that British is punctuation outside of the quotes,
On Tue, 2008-05-13 at 17:33 +0100, Alan Cox wrote:
> On Tue, 13 May 2008 12:22:51 -0400
> Pat Suwalski <[EMAIL PROTECTED]> wrote:
>
> > Alan Cox wrote:
> > > Put the English quotes in the en_US and en_GB translations, put German
> > > quotes in the de ones and so on.
> >
> > This, if course, make
On Tue, 2008-05-13 at 17:36 +0100, Alan Cox wrote:
> > Honestly, other than being pedantic, I don't see the
> > problem with UTF-8 in the C locale. Does it cause
> > any *actual* problems? I've never once gotten a bug
> > report against g-d-u about this.
>
> Sort order, comparisons, printing, st
O/H Shaun McCance έγραψε:
> On Tue, 2008-05-13 at 16:22 +0100, Simos Xenitellis wrote:
>
>> I think the most important question to answer is whether we want to make
>> POT files non-ASCII. That is, once messages have “”‘’, etc, then GNOME
>> will be available for Unicode locales only.
>> If on
> Honestly, other than being pedantic, I don't see the
> problem with UTF-8 in the C locale. Does it cause
> any *actual* problems? I've never once gotten a bug
> report against g-d-u about this.
Sort order, comparisons, printing, string lengths when using locale aware
functions, and no doubt a
On Tue, 13 May 2008 12:22:51 -0400
Pat Suwalski <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > Put the English quotes in the en_US and en_GB translations, put German
> > quotes in the de ones and so on.
>
> This, if course, makes something like the very tiny en_CA locale into a
> rather full l
On Tue, 2008-05-13 at 16:54 +0100, Alan Cox wrote:
> > Don't we already have plenty of non-ASCII POT files?
> > I know gnome-doc-utils is non-ASCII.
>
> That would be a bug...
>
> > that we've had all this functionality for quite a while, but
> > we're still typing as if we're on old typewriters.
Alan Cox wrote:
> Put the English quotes in the en_US and en_GB translations, put German
> quotes in the de ones and so on.
This, if course, makes something like the very tiny en_CA locale into a
rather full locale. I suppose many generic messages can go into just "en".
--Pat
___
2008-05-13 klockan 16:19 skrev Christian Neumair:
> Alex Jones proposed [1] to change the quotation marks in Nautilus
> strings from the ASCII representation "..." to the unicode variant
> “...”.
>
> I think the proposed quotation marks are aesthetically more pleasing,
> but I don't want to chang
> Don't we already have plenty of non-ASCII POT files?
> I know gnome-doc-utils is non-ASCII.
That would be a bug...
> that we've had all this functionality for quite a while, but
> we're still typing as if we're on old typewriters. What do
> we need to do, as programmers, to get the world out o
> They also tend to fail horribly when pasting into a non-Unicode
> terminal, which is still often the case over SSH. Probably not a huge
> desktop consideration, though. Every distribution I know of uses Unicode
> by default on the local terminal at this point.
Doesn't matter for translations
On Tue, 2008-05-13 at 16:22 +0100, Simos Xenitellis wrote:
>
> I think the most important question to answer is whether we want to make
> POT files non-ASCII. That is, once messages have “”‘’, etc, then GNOME
> will be available for Unicode locales only.
> If one starts GNOME with a C or a legac
On Tue, May 13, 2008 at 5:22 PM, Simos Xenitellis
<[EMAIL PROTECTED]> wrote:
> I think the most important question to answer is whether we want to make
> POT files non-ASCII. That is, once messages have ""'', etc, then GNOME
> will be available for Unicode locales only.
> If one starts GNOME wi
El mar, 13-05-2008 a las 10:18 -0500, Shaun McCance escribió:
> > The only problem I see is some languages use different characters
> for
> > quoting. ASCII ones are somewhat neutral.
>
> Other languages will translate the strings anyway.
In fact, we in Spanish change quotation marks to «». We'll
On Tue, 2008-05-13 at 10:45 -0400, Pat Suwalski wrote:
> My objection may seem silly, but since there is no way to type it on any
> keyboard out there, that's a bit of a hindrance. Short of using the
> character map and searching, one has to resolve to using "smart
> substitution" editors like O
O/H Pat Suwalski έγραψε:
> My objection may seem silly, but since there is no way to type it on any
> keyboard out there, that's a bit of a hindrance. Short of using the
> character map and searching, one has to resolve to using "smart
> substitution" editors like OpenOffice to get the character
Well, that brings up the problem of quoting text in different languages.
For example, as far as I know:
* “English text”
* „German text“
* «French text»
* ...and so on
If this change has to be made, someone should warn the translators to
use consistently translated quote-marks all around.
But
On Tue, 2008-05-13 at 17:16 +0200, Patryk Zawadzki wrote:
> On Tue, May 13, 2008 at 4:19 PM, Christian Neumair <[EMAIL PROTECTED]> wrote:
> > Alex Jones proposed [1] to change the quotation marks in Nautilus
> > strings from the ASCII representation "..." to the unicode variant
> > "...".
>
> T
On Tue, May 13, 2008 at 4:19 PM, Christian Neumair <[EMAIL PROTECTED]> wrote:
> Alex Jones proposed [1] to change the quotation marks in Nautilus
> strings from the ASCII representation "..." to the unicode variant
> "...".
The only problem I see is some languages use different characters for
q
My objection may seem silly, but since there is no way to type it on any
keyboard out there, that's a bit of a hindrance. Short of using the
character map and searching, one has to resolve to using "smart
substitution" editors like OpenOffice to get the characters.
They also tend to fail horrib
Alex Jones proposed [1] to change the quotation marks in Nautilus
strings from the ASCII representation "..." to the unicode variant
“...”.
I think the proposed quotation marks are aesthetically more pleasing,
but I don't want to change this unless there is a GNOME-wide policy.
I hereby propose
75 matches
Mail list logo
