joe-editor-general

Re: [joe] gettext for JOE

[Sebastien K. <se...@ko...>]

On Tue, May 23, 2006 at 07:13:58PM +0200, Sebastien Koechlin wrote:
> I tried to start a french translation (as I use joe since about 1994), but
> I have an error when compiling it.

I was able to compile joe wednesday, but today I have errors again, automake
and autoconf are reporting errors.

./INSTALL is not up to date, there is nothing about automake and autoconf,
minimal version to use and in which order they should be run.

Anyway, here is a first french translation, started on joe.pot 1.2 and
patched to upgrade to 1.5.

	http://koocotte.org/joe/

There are some strings not translated

-because I don't really understand what does it means and when joe print it:

	is joe keymap really a map for keyboard? Is it about keys or
	characters, or glyphs? I don't understand what is a buffer, Menu
	explorer, Search prompting, Completion mode/Menu explorer,
	transposed menu, anchored block...

-I keep If/Then/Else/Endif/Repeat in macro in english, because I think it
would break a lot of things, and I don't want joe to understand commands
depending of configured locale.

-I did not translate option menu (^T) for the moment. French take more space
and I have to find really small text to fit in thoses littles spaces,
understandable both by old (having english menu for years) and new users.

-Finding options are not translated because I have problems with characters
list. When the same value is used more than once, they are present
only one time, for example:

	#: cmd.c:216 usearch.c:557
	msgid "iI"

iI is for "Edit anyway" in cmd and "Ignore" in usearch.
Should I duplicate thoses lines, one for cmd and one for usearch?

How a po file is updated to match next update/new strings?

-- 
Seb, autocuiseur

Re: [joe] gettext for JOE

[Joseph H A. <jh...@wo...>]

Koblinger Egmont <eg...@uh...> wrote:

>On Wed, May 31, 2006 at 08:38:38AM -0400, Joseph H Allen wrote:

>> I'll take a look at some of these GNU tools today and get back to you.  I
>> didn't notice any special support for this in gettext(), so either I missed
>> it, it's somewhere else, or they just have some ad-hoc acceptance of letters
>> for many different languages.

>These are defined in glibc locales, their source is probably installed under
>/usr/share/i18n, and you can query the locale database by "locale -k
>LC_MESSAGES", here you'll see "yesexpr" and friends. So there's only a
>common solution for yes/no questions. The libc interface is the
>  int rpmatch(const char *reply)
>function.

>In joe there are many different kinds of questions, e.g. (S)teel, (I)gnore
>or (Q)uit, and similar ones. So sure an own implemntation is needed to be
>able to translate these three letters. Sending these letters (well, better:
>letter sets) to gettext is a quite good idea. (Actually it seems to me now
>that GNU coreutils also uses an own implemntation of rpmatch instead of
>using libc, it takes the "yes" and "no" regexps from gettext.)
>
>Just be sure to prefix all these letters with some context prefix so that
>what happens to be the same letter in English in two completely different
>circumstances are not necessarily the same in other languages.

>> I'm curious how they support UTF-8 for this.

>I don't know, but if you translate these letters via gettext then it's up to
>you ;)

I've just checked internationalized "yes"/"no" checking into CVS.  I've
decided to use gettext instead of LC_MESSAGES, so there are strings in
joe.pot which give the set of yes and no characters.  They are in this
format:

	"yY<>yY"

The characters to left of the <> should be in the 8-bit version of the
locale.  The characters to the right of the <> should be in UTF-8.

There are strings for "yes", "no", "backup" and "rest" (for the find &
replace prompt).  I still need to add strings for the search and replace
options prompt.

Joe

Re: [joe] gettext for JOE

[Egmont K. <eg...@uh...>]

On Fri, Jun 02, 2006 at 11:10:29AM -0400, Joseph H Allen wrote:

> The characters to left of the <> should be in the 8-bit version of the
> locale.  The characters to the right of the <> should be in UTF-8.

Brrrrrrrrr. Sorry but this sounds terrible.

Joe already performs plenty of charset conversions, even when reading .po
files (based on their header), I can't see why it couldn't do it here.

Translators are usually not developers. They just sit at their properly
configured system and use some tool (e.g. joe, kbabel...) and type the
accented letters from their keyboard. Usually they are unable to "hack" in
these kinds of various encodings into a file. They rightly expect things
"just work", that is, if they type a particular accented letter, it should
always remain the same and always mean that same letter.

Tools such as kbabel, msgfmt and so on may also easily fail if a .po file
claims it is UTF-8 while it isn't actually. They may fail to load or handle
these files. And porting joe to real gettext will be harder, too.

Furthermore, there might be languages with more old-fashioned locales, e.g.
ru_RU.KOI8-R vs. ru_RU.ISO-8859-5.



-- 
Egmont

Re: [joe] gettext for JOE

[Joseph H A. <jh...@wo...>]

Egmont Koblinger <eg...@uh...> wrote:

>On Fri, Jun 02, 2006 at 11:10:29AM -0400, Joseph H Allen wrote:
>> The characters to left of the <> should be in the 8-bit version of the
>> locale.  The characters to the right of the <> should be in UTF-8.

>Brrrrrrrrr. Sorry but this sounds terrible.

>Joe already performs plenty of charset conversions, even when reading .po
>files (based on their header), I can't see why it couldn't do it here.

You're right, it's bad.  I'm eliminating the <>.  The characters now just
have to match the character set of the .po file.


Joe

Re: [joe] gettext for JOE

[Joseph H A. <jhallen@TheWorld.com>]

Sebastien Koechlin <se...@ko...> wrote:

>I was able to compile joe wednesday, but today I have errors again, automake
>and autoconf are reporting errors.

I've been working on it...

>./INSTALL is not up to date, there is nothing about automake and autoconf,
>minimal version to use and in which order they should be run.

It's in INSTALL.cvs.  You need to type ./autojoe to rerun all the auto junk.

>Anyway, here is a first french translation, started on joe.pot 1.2 and
>patched to upgrade to 1.5.
>
>	http://koocotte.org/joe/

Cool!

>There are some strings not translated

I think this is OK.

>-because I don't really understand what does it means and when joe print it:

>	is joe keymap really a map for keyboard? Is it about keys or
>	characters, or glyphs?

It's the name of a keymap in the joerc file (like ":main")- a table of key
sequence to macro bindings.

>I don't understand what is a buffer,

A file loaded into JOE.

>Menu
>	explorer,

If you jump into a menu and click on a directory, then if this option is
set, it leaves the cursor in the menu, otherwise it puts it back in the
prompt.

>Search prompting,

When you hit ^KF, the prompt suggests reusing the previously entered search
string when this is set.

>Completion mode/

Maybe this is -csmode?  It ^KF just repeats the search instead of prompting
for a new string.

>transposed menu

The rows and columns of file name completion menus are swapped.

>anchored block...

I was thinking about this.  I will try to add comments in the source code
(since there is a reference to the source code in the comment above the
msgid) explaining the meaning of short strings.

>-I keep If/Then/Else/Endif/Repeat in macro in english, because I think it
>would break a lot of things, and I don't want joe to understand commands
>depending of configured locale.

>-I did not translate option menu (^T) for the moment. French take more space
>and I have to find really small text to fit in thoses littles spaces,
>understandable both by old (having english menu for years) and new users.

You can make them longer, but then fewer will fit on the screen (the number
of columns in ^T gets reduced).

>-Finding options are not translated because I have problems with characters
>list. When the same value is used more than once, they are present
>only one time, for example:
>
>	#: cmd.c:216 usearch.c:557
>	msgid "iI"

I will see if there is any way to force xgettext to leave these as separate
strings.  One stupid way is to put a prefix string in the msgid string, but
I'd prefer not to do that.

>iI is for "Edit anyway" in cmd and "Ignore" in usearch.
>Should I duplicate thoses lines, one for cmd and one for usearch?

Let me think about it, update CVS and contact you again.

>How a po file is updated to match next update/new strings?

There is a program called msgmerge which does this.  It keeps the existing
translations, adds msgids for new strings and comments out obsolete strings.


Joe

Re: [joe] gettext for JOE

[Joseph H A. <jh...@th...>]

Sebastien Koechlin <se...@ko...> wrote:

>-Finding options are not translated because I have problems with characters
>list. When the same value is used more than once, they are present
>only one time, for example:
>
>	#: cmd.c:216 usearch.c:557
>	msgid "iI"
>
>iI is for "Edit anyway" in cmd and "Ignore" in usearch.
>Should I duplicate thoses lines, one for cmd and one for usearch?

I've fixed this in CVS.  Now you can have comment prefixes in gettext()
strings- if the comments are different, you get separate entries in joe.pot. 
So for the above, joe.pot now has:

	msgid "|ignore lock, continue with edit|iI"

and:

	msgid "|ignore case|iI"

You can leave the comments out of the msgstr if you want.

This method is suggested in the gnu-gettext() documentation, but for a
different purpose.


So I've updated the "joe.pot" file.  You should do this (assuming you want
to translate these):

msgmerge fr.po joe.pot >new

If 'new' looks OK,

 mv new fr.po


Joe