After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 97571 - Book: Internationalisation and Translation chapter is incomplete
Book: Internationalisation and Translation chapter is incomplete
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: general
2.0
Other other
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2002-11-03 17:48 UTC by Ole Laursen
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The missing i18n chapter (13.86 KB, patch)
2002-11-03 17:50 UTC, Ole Laursen
none Details | Review
A better patch (15.88 KB, patch)
2002-11-03 18:14 UTC, Ole Laursen
none Details | Review

Description Ole Laursen 2002-11-03 17:48:34 UTC
I've written the missing i18n chapter. The result can be seen here:

  http://www.cs.auc.dk/~olau/ch17.html

I've included

  - a description of how to use gettext and how it works

  - a list of common pitfalls (I'm maintaining the Danish translations of
    Gnome so I know most of these by heart :-)

  - a short description of how to approach gnome-i18n to get an 
    application translated

I'm sorry that the XML isn't indented like the rest of the book, but I'm
using PSGML with Emacs and things just ended up like this before I noticed.
It doesn't affect the output, though.

A last thing: I've shamelessly included a pointer to my little compose
library. I hope this is OK as proper i18n is impossible to do without a
composition library, and my own is the only one I know works with Gtkmm
(well, it's actually also the only one I know that is being maintained).
Comment 1 Ole Laursen 2002-11-03 17:50:29 UTC
Created attachment 12019 [details] [review]
The missing i18n chapter
Comment 2 Ole Laursen 2002-11-03 18:13:53 UTC
I forgot to patch the ChangeLog and include myself in the author list.
Try the following patch instead. I've changed the author part into
something more Docbook correct I hope.
Comment 3 Ole Laursen 2002-11-03 18:14:53 UTC
Created attachment 12020 [details] [review]
A better patch
Comment 4 Murray Cumming 2002-11-03 18:15:46 UTC
Thanks very much. I will apply this later. Be prepared for me to
rewrite it though.
Comment 5 Murray Cumming 2002-11-03 21:03:51 UTC
I needed to completely rewrite most of it because the english is so
verbose. I have not yet rewritten the "how gettext works" and "getting
help with translations" sections, but I will  do that later.

Also, we need to add some information about the build and translation
system - at the moment this isn't much more than "use gettext()".

Please check the new text for factual correctness. In particular,
could you confirm that source code should always contain _english_
string literals. If not, how would someone write an application
primarily for arabic without writing arabic in the source code?
Comment 6 Ole Laursen 2002-11-04 18:13:10 UTC
As it is now gettext doesn't seem to work properly with non-ASCII
characters. So the source code strings *needs* to be in English. (I
think the gettext thing is actually a minor issue, but I have no idea
of why or how.)

So if you are writing an Arabic application that should support other
languages, you simply write English strings in the code and provide an
xx.po file with the Arabic translation. If you don't care about other
languages, it would be easiest just to write the strings in inline
UTF-8 encoded Arabic, I guess. And completely avoid gettext. But then
there is no i18n.

It seems my timing is bad though. Malcolm Tredinnick and Christian
Rose is just in the midst of writing a general i18n howto:

http://mail.gnome.org/archives/gnome-i18n/2002-November/msg00028.html

The "pitfalls" section could probably be shared almost completely with
his work (I don't know yet, though, I haven't had the time to read
it). I'll take a look at it soon.
Comment 7 Murray Cumming 2002-11-11 22:25:21 UTC
As a first step to explaining the build files changes for i18n, I
think we should change gtkmm_hello so that it doesn't use
GNOME-specific stuff - so that means no intltools. Alternatively we
need to say why it's a good idea to use intltools everywhere.
Comment 8 Ole Laursen 2002-11-14 22:50:55 UTC
Hm, it seems I must have been on crack. I'm pretty sure I read
somewhere that the libraries where supposed to take care of setting up
gettext. But I'm pretty sure now that this is completely wrong. At
least you need:

  textdomain(GETTEXT_PACKAGE);
  bind_textdomain_codeset(GETTEXT_PACKAGE, "UTF-8");

And possibly one line more to make it possible to ./configure where
the program looks for .mo files. I'll try to test this.

Regarding no-Gnome usage: intltool is not really Gnome specific as far
as I'm aware of, but OTOH if you don't have any Gnome stuff (such as
.desktop files), it won't be of much use. Hm, I need to do some
research on this.

I think we need a more complete example to cut-and-paste from, and
some refactoring to benefit from Malcolm's document. I'll provide a
patch when I get the time (and see if I can change my style to
something more terse :-).
Comment 9 Murray Cumming 2002-11-15 19:19:34 UTC
OK, but I do think the first step should be to remove intltools from
gtkmm_hello and replace it with something more generically gettext.
Comment 10 Murray Cumming 2002-12-02 22:15:28 UTC
I have converted gtkmm_hello and explained gettext in the book.