UTF-8 is designed so that subsequences are unambiguous. You won’t get a byte less than 0×80 in any part of a multi-byte sequence. bytes 0×00-0x7F map directly to 7-bit ASCII.

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 breaking C?

Like or Dislike: 0  0

As to universal character names, it is implementation-defined what actually will be contained in the character array. I.e. if you have char *s = “\u…” then you have no idea how to display text pointed to by that variable in a gtk label. Also, once you have that line of code, it won’t by magic change “to different encodings”, it will be whatever byte sequences the compiler will put in there and that’s it. It’s pretty much the same as “abc” – it won’t by magic be valid UTF-16, no matter how you compile the file.

And by the way, MS does not implement C99 (surprised?).

Like or Dislike: 0  0

SHIFT-JIS is almost backward-compatible with ASCII (two characters differ).

@behdad: C99 defines a super-portable way to encode non-ASCII strings (using UCNs, as described in the added section in the post above). This is what gcc says about UCNs:

$ cat t.c
int main(void)
{
char* str = “\u0399″;

return 0;
}
$ gcc t.c -o t
t.c:3:14: warning: universal character names are only valid in C++ and C99
$ _

This means that UCNs work in gcc, but they produce a warning by default.

Using hand-encoded UTF-8 strings (such as “\xCE\x80″) makes the code less portable to different encodinds.

Like or Dislike: 0  0

Like or Dislike: 0  0

Like or Dislike: 0  0

That is, bytes with the 8th bit set. Both iso-8859-x and utf-8 can have bytes that the value is >127.

Or, bytes with value <32 (control characters). That could be the case with UTF-8 when a character has codepoint value >127.

Like or Dislike: 0  0

Maybe I’m missing something?

Like or Dislike: 0  0

Like or Dislike: 0  0

Like or Dislike: 0  0

printf(_(“file not found: %s\n”));

might not be very friendly, but it’s direct and equally easy to translate, regardless of what quotes your region uses. There exist english translations of a lot of english software already (en_UK etc) so adding en_US isn’t creating a major new translation job.

Obviously I wouldn’t bother changing old strings, as long as compilers aren’t erroring anyway, but a gradual shift doesn’t seem to be a lot of work.

Like or Dislike: 0  0

@James, Davyd: If those strings are for the UI, it would be somewhat more difficult for the translators to figure out what the message says.

The current summary for this looks like: It appears to be ok to have UI strings with non-ASCII characters in GNOME applications, though it’s not clear yet if it is ok for libraries (such as glib, gtk+). This is because these libraries may be used for embedded systems, etc where compilers may not like non-ascii source strings.

Like or Dislike: 0  0

Like or Dislike: 0  0