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
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 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 do a
(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 temporary
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 specifications
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 is
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 utf-8
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
that is
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
that is
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
point depends
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 show
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 function
that
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 believe
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 call gtk_label_new
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 _(blah)
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 for smart
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,
we're
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 believe
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 UTF-8 whether
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 ceases
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 documents
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 whether
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 proposal to
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 knowledge of
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 other
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
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 them.
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 up
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 probably a perl
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
listen. Consider a
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
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 strings
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 not.
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
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 are,
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
mentioned.
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
moment you introduce UTF-8 bytesequences into non utf-8 locales.
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
MSB
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
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 theory
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 what
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, do
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 of
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.
Sort order,
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
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
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 'intltool-update
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 the default
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 and
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
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
quoting.
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
The only
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
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 characters.
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
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
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 keep
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 with a C
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 legacy
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 but
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 of
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 change this
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
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. What do
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 locale. I
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 few
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, string
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 one starts
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, makes something like
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,
en_US:
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 to
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 quotation marks are
72 matches
Mail list logo
