Menu
▾
▴
joe-editor-general
|
From: Joseph H A. <jhallen@TheWorld.com> - 2006-05-22 04:36:45
|
I've finally added gettext() support for JOE- it's now checked into CVS. I've checked in the messages.po file as well. It would be helpful if someone would create one translation. I still need to set up ./configure to install everything properly. Any hints or suggestions would be welcome. I don't know which subdirectory to put the translation files in or how to tell configure the location (it's complaining about a missing SUBDIR definition). Also I'm not sure how to deal with the manual page or help text in the joerc file. There is an :include command for the joerc file- perhaps translations of the help screens should go in different files, or configure can merge them in. Joe |
|
From: Egmont K. <eg...@uh...> - 2006-05-22 13:47:01
|
Hi, > I've finally added gettext() support for JOE- it's now checked into CVS. Cool :-) > I've checked in the messages.po file as well. It would be helpful if > someone would create one translation. I'd be happy to create the Hungarian translation, but I'm unable to update my joe cvs tree since a long time ago. At this moment it says cvs [update aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: No route to host > I still need to set up ./configure to install everything properly. Any > hints or suggestions would be welcome. I don't know which subdirectory to > put the translation files in The subdirectory called "po" is probably the most standard and GNU way. > or how to tell configure the location (it's > complaining about a missing SUBDIR definition). > > Also I'm not sure how to deal with the manual page The standard installed location for intl manpages is a subdirectory with the language code between the "man" and "man<sect>" directories, for example English => /usr/share/man/man1/joe.1 Hungarian => /usr/share/man/hu/man1/joe.1 I don't know if there's a standard way where to put these inside the source, and what to call them (e.g. joe.hu.1) if you want to avoid plenty of subdirs within the source (which is a reasonable idea). > or help text in the joerc > file. There is an :include command for the joerc file- perhaps translations > of the help screens should go in different files, or configure can merge > them in. Unfortunately I cannot help in autoconf details, and have no good idea how to solve the translating of help texts. Maybe the :include command could be used, if it's tricked a bit so that e.g. ":include foo" includes "foo.hu" if it's available and locale is hungarian, and falls back to "foo". It's a bit ugly since it trashes /etc/joe by putting many many files there. Or maybe joerc itself could contain the translations for many languages with a special syntax, e.g. {Basic[hu] \i .... This is a bit similar to the .desktop files that form the Gnome/KDE application menu. -- Egmont |
|
From: Joseph H A. <jhallen@TheWorld.com> - 2006-05-22 14:35:18
|
Egmont Koblinger <eg...@uh...> wrote: >I'd be happy to create the Hungarian translation, but I'm unable to update >my joe cvs tree since a long time ago. At this moment it says >cvs [update aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 >failed: No route to host Sourceforge has changed their cvs servers, so you need to do this: mv joe-current joe-current-old cvs -d :pserver:ano...@jo...:/cvsroot/joe-editor co joe-current Joe |
|
From: Josip R. <jo...@sr...> - 2006-05-22 14:42:10
|
On Mon, May 22, 2006 at 10:19:24AM -0400, Joseph H Allen wrote: > >I'd be happy to create the Hungarian translation, but I'm unable to update > >my joe cvs tree since a long time ago. At this moment it says > >cvs [update aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 > >failed: No route to host > > Sourceforge has changed their cvs servers, so you need to do this: > > mv joe-current joe-current-old > cvs -d :pserver:ano...@jo...:/cvsroot/joe-editor co joe-current ITYM find joe-current/ -path '*/CVS/Root' | xargs perl -pi -e s,cvs.joe-editor,joe-editor.cvs, -- 2. That which causes joy or happiness. |
|
From: Mikhael G. <mi...@ho...> - 2006-05-22 16:06:06
|
On 22 May 2006 16:41:59 +0200, Josip Rodin wrote: > > find joe-current/ -path '*/CVS/Root' | xargs perl -pi -e s,cvs.joe-editor,joe-editor.cvs, Yes, this is what I do too. But you have a typo in the old server name: find . -name Root | xargs perl -pi -e s/cvs/joe-editor.cvs/ Regards, Mikhael. |
|
From: Josip R. <jo...@sr...> - 2006-05-22 16:11:39
|
On Mon, May 22, 2006 at 04:05:46PM +0000, Mikhael Goikhman wrote: > > find joe-current/ -path '*/CVS/Root' | xargs perl -pi -e s,cvs.joe-editor,joe-editor.cvs, > > Yes, this is what I do too. But you have a typo in the old server name: > > find . -name Root | xargs perl -pi -e s/cvs/joe-editor.cvs/ Well, I previously used cvs.joe-editor.sourceforge.net, and now the first two items are swapped, joe-editor.cvs.sourceforge.net, so there is no typo, only a different prior usage. -- 2. That which causes joy or happiness. |
|
From: Joseph H A. <jhallen@TheWorld.com> - 2006-05-22 20:36:44
|
There's now a fake 'de.po' file in the po directory. The infrastructure appears to be working: if I type 'LANG=de_DE joe sdfdsf', it says "New File 1" instead of "New File". Joe |
|
From: Joseph H A. <jhallen@TheWorld.com> - 2006-05-24 00:19:41
|
Sebastien Koechlin <se...@ko...> wrote: >On Mon, May 22, 2006 at 04:13:59PM -0400, Joseph H Allen wrote: >I tried to start a french translation (as I use joe since about 1994), but >I hava an error when compiling it. >I grab fresh sources from CVS, run > ./configure --with-included-gettext >or just > ./configure >but I have the following error (problem with substitution?): Update your sandbox (cvs update -d .). Also rerun the automake and autoconf tools. Sometimes the CVS mirror is behind. You got the right version when the top of the ChangeLog file says: Tue May 23 17:28:48 EDT 2006 Switch to my own gettext() library. I too have been having these problems, depending on the system, so I've just checked in a new version: I've decided that I'm not going to rely on the system's gettext and I'm not including GNU-gettext with JOE. Instead, I've written my own. A major benefit of using my own is that these compile problems go away, and JOE remains dependency free. So now when you type make install, the po/*.po files just get copied to /etc/joe/lang. JOE will read the .po files directly, so there is no need for the binary .gmo or .mo files (but this may change). However, the .po files are in exactly the same format so we can use the nice existing tools, like xgettext and msgmerge. I'm still deciding what to do about the joerc file. Really there should be a joerc for each language, but then it becomes very hard to add new features to the editor. I guess I need versions of patch/diff which ignore comments (Yura Kalinichenko has actually translated my joerc file comments into Russian)- then I could make a change and merge it into every language, like msgmerge. Also there's the problem of UTF-8 vs. non-UTF-8 joerc files. Joe |
|
From: Egmont K. <eg...@uh...> - 2006-05-29 14:25:25
|
On Tue, May 23, 2006 at 07:08:46PM -0400, Joseph H Allen wrote:
Hi,
> Switch to my own gettext() library.
>
> I too have been having these problems, depending on the system, so I've just
> checked in a new version: I've decided that I'm not going to rely on the
> system's gettext and I'm not including GNU-gettext with JOE. Instead, I've
> written my own. A major benefit of using my own is that these compile
> problems go away, and JOE remains dependency free.
>
> So now when you type make install, the po/*.po files just get copied to
> /etc/joe/lang. JOE will read the .po files directly, so there is no need
> for the binary .gmo or .mo files (but this may change).
Could this be a compile time option? I'm using a Linux system, here there's
absolutely no problem with the gettext system, it doesn't bring run-time
dependency (as it's part of glibc), and it's so ugly to see individual
solutions for problems that have common well-known solution.
(We're building a distro and have several scripts handling
/usr/share/locale/*/*/*.mo files. For example languages not supported by our
installer are dropped from the installer's code to save space. Here then
we'd need to take special care of joe, since the current file dropping rules
would keep all its languages. Other example: since our distro is fully
UTF-8, we automatically convert all the .mo files to UTF-8 during package
build, so that we save run-time CPU time by avoiding the need of converting.
This is again an issue which should need special attention regarding joe. It
would be so nice to see joe smoothly integrating to the rest of the system.)
BTW there's an off-by-one bug when parsing the charset of the .po file.
Currently in row 84 of gettext.c the code to jump over the "charset=" text
is this:
p += sizeof("charset=");
but sizeof() includes the terminating zero, hence if my file is encoded in
UTF-8, joe tries to look up the charset called "TF-8". It should be strlen()
or a hard-coded constant of 8 (as this text is unlikely to change).
--
Egmont
|
|
From: Joseph H A. <jhallen@TheWorld.com> - 2006-05-30 14:19:19
|
Egmont Koblinger <eg...@uh...> wrote: >Hi, >> Switch to my own gettext() library. >Could this be a compile time option? I'm using a Linux system, here there's >absolutely no problem with the gettext system, it doesn't bring run-time >dependency (as it's part of glibc), and it's so ugly to see individual >solutions for problems that have common well-known solution. Hi Egmont, thanks for the bug fix. I'll look into making this an option: it ends up being a big puzzle, because gnu-gettext() is dependent on the system's setlocale and nl_langinfo, which are frequently broken (many versions of SUN and also Cygwin). Also, GNU-gettext() would have you include the gettext() code along with each package, in the intl/ directory. BTW, how much of a problem is it having the .mo files in joe/lang instead of share/locale/.. ? I like them in the joe/lang directory, but standard gettext() Makefile doesn't support this (and is otherwise frequently broken). Joe |
|
From: Mikhael G. <mi...@ho...> - 2006-05-30 15:39:50
|
On 30 May 2006 10:18:51 -0400, Joseph H Allen wrote: > > BTW, how much of a problem is it having the .mo files in joe/lang > instead of share/locale/.. ? I like them in the joe/lang directory, but > standard gettext() Makefile doesn't support this (and is otherwise > frequently broken). Personally, I think all joe files (configs, syntax) should reside in $datadir/joe, not $sysconfdir/joe, i.e. in /usr/share/joe, not /etc/joe. Naturally, I prefer the standard $datadir/locale/ too, because if every project decides to add dozens of subdirectories for translation, then the system would end up with thousands of subdirectories (instead of dozens). Just my opinion, based on the conventions from other common projects. Regards, Mikhael. |
|
From: Josip R. <jo...@sr...> - 2006-05-30 16:23:58
|
On Tue, May 30, 2006 at 03:39:17PM +0000, Mikhael Goikhman wrote:
> > BTW, how much of a problem is it having the .mo files in joe/lang
> > instead of share/locale/.. ? I like them in the joe/lang directory, but
>
> Personally, I think all joe files (configs, syntax) should reside in
> $datadir/joe, not $sysconfdir/joe, i.e. in /usr/share/joe, not /etc/joe.
There is no point in moving configuration files out of $sysconfdir,
that's simply contrary to the FHS (and to common sense).
Syntax files could be treated as data files and the shipped ones can be put
to a place below $datadir, as long as they can be overridden from
$sysconfdir (and $HOME).
--
2. That which causes joy or happiness.
|
|
From: Mikhael G. <mi...@ho...> - 2006-05-30 17:34:45
|
On 30 May 2006 18:23:50 +0200, Josip Rodin wrote: > > There is no point in moving configuration files out of $sysconfdir, > that's simply contrary to the FHS (and to common sense). Don't be so sure (about the common sence). :) If, say, the configuration supports run-time includes, then it makes sense to divide it to loadable modules (think emacs scripts). Then all these modules belong to share/. I.e. if it is a static declaration, it may belong to /etc, if it is more like a programming language, such configuration does not belong to /etc. Regards, Mikhael. |
|
From: Mikhael G. <mi...@ho...> - 2006-05-30 18:14:44
|
On 30 May 2006 18:23:50 +0200, Josip Rodin wrote: > > On Tue, May 30, 2006 at 03:39:17PM +0000, Mikhael Goikhman wrote: > > > > Personally, I think all joe files (configs, syntax) should reside in > > $datadir/joe, not $sysconfdir/joe, i.e. in /usr/share/joe, not /etc/joe. > > There is no point in moving configuration files out of $sysconfdir, > that's simply contrary to the FHS (and to common sense). For me it would be very sensible and useful, because this simplifies the logic of loading data files regardless of their type (i.e. config, syntax highlighting, charmaps and more). Here is, for example, the way we handle the configuration in FVWM. I think vim and emacs use similar logic (they don't have /etc as well). There are 2 directories for configuration files: user-specific FVWM_USERDIR ~/.fvwm (changeable by $FVWM_USERDIR) system-wide FVWM_DATADIR /usr/share/fvwm ($datadir/fvwm) The main config file and all includes are searched first in FVWM_USERDIR, then in FVWM_DATADIR. Regards, Mikhael. |
|
From: Matthew M. <ma...@ma...> - 2006-05-30 18:18:51
|
On Tue, May 30, 2006 at 06:14:16PM +0000, Mikhael Goikhman wrote:
> user-specific FVWM_USERDIR ~/.fvwm (changeable by $FVWM_USERDIR)
> system-wide FVWM_DATADIR /usr/share/fvwm ($datadir/fvwm)
Better:
user-specific ~/.apprc
system-wide /etc/app/app.rc
defaults /usr/share/app/app.rc
--
Matthew Miller ma...@ma... <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
|
|
From: Mikhael G. <mi...@ho...> - 2006-05-30 18:33:06
|
On 30 May 2006 14:18:46 -0400, Matthew Miller wrote: > > On Tue, May 30, 2006 at 06:14:16PM +0000, Mikhael Goikhman wrote: > > user-specific FVWM_USERDIR ~/.fvwm (changeable by $FVWM_USERDIR) > > system-wide FVWM_DATADIR /usr/share/fvwm ($datadir/fvwm) > > Better: > > user-specific ~/.apprc > system-wide /etc/app/app.rc > defaults /usr/share/app/app.rc You speak about applications with a single rc file. I speak about apps with hundreds of config files, like vim, emacs, fvwm and joe. BTW, a slightly related bug report. After "echo > ~/.joe/syntax/perl.jsf" joe core-dumps on any perl file. Regards, Mikhael. |
|
From: Josip R. <jo...@sr...> - 2006-05-30 19:10:11
|
On Tue, May 30, 2006 at 06:32:52PM +0000, Mikhael Goikhman wrote:
> > > user-specific FVWM_USERDIR ~/.fvwm (changeable by $FVWM_USERDIR)
> > > system-wide FVWM_DATADIR /usr/share/fvwm ($datadir/fvwm)
> >
> > Better:
> >
> > user-specific ~/.apprc
> > system-wide /etc/app/app.rc
> > defaults /usr/share/app/app.rc
>
> You speak about applications with a single rc file. I speak about apps
> with hundreds of config files, like vim, emacs, fvwm and joe.
That's completely irrelevant. If you put settings into $datadir, and let
these settings be mindlessly overwritten on each upgrade of the software
package, then that's just plain old broken. Regardless of whether these
settings were in 1 file or in 374 of them.
Let's not pretend that the notion of system-wide configuration files was
invented yesterday...
--
2. That which causes joy or happiness.
|
|
From: Mikhael G. <mi...@ho...> - 2006-05-30 20:57:02
|
On 30 May 2006 21:10:01 +0200, Josip Rodin wrote: > > On Tue, May 30, 2006 at 06:32:52PM +0000, Mikhael Goikhman wrote: > > > > user-specific FVWM_USERDIR ~/.fvwm (changeable by $FVWM_USERDIR) > > > > system-wide FVWM_DATADIR /usr/share/fvwm ($datadir/fvwm) > > > > > > Better: > > > > > > user-specific ~/.apprc > > > system-wide /etc/app/app.rc > > > defaults /usr/share/app/app.rc > > > > You speak about applications with a single rc file. I speak about apps > > with hundreds of config files, like vim, emacs, fvwm and joe. > > That's completely irrelevant. If you put settings into $datadir, and let > these settings be mindlessly overwritten on each upgrade of the software > package, then that's just plain old broken. Regardless of whether these > settings were in 1 file or in 374 of them. > > Let's not pretend that the notion of system-wide configuration files was > invented yesterday... Seems it was my mistake to use term "system-wide" when a better term for it would be "global default". I am not really against additional config directories in the middle, but this is often not needed in practice. Regards, Mikhael. |
|
From: Koblinger E. <eg...@uh...> - 2006-05-30 18:52:27
|
On Tue, May 30, 2006 at 03:39:17PM +0000, Mikhael Goikhman wrote:
> On 30 May 2006 10:18:51 -0400, Joseph H Allen wrote:
> >
> > BTW, how much of a problem is it having the .mo files in joe/lang
> > instead of share/locale/.. ? I like them in the joe/lang directory, but
> > standard gettext() Makefile doesn't support this (and is otherwise
> > frequently broken).
>
> Personally, I think all joe files (configs, syntax) should reside in
> $datadir/joe, not $sysconfdir/joe, i.e. in /usr/share/joe, not /etc/joe.
I guess it's a quite a matter of personal taste. Actually I have no pros or
cons for either of these. Probably what I'd like the best is:
- put config files (that are quite likely being edited by the sysadmin, e.g.
joerc) to /etc/joe
- put text files that are unlikely to being edited (e.g. syntax highlight
rules, translations) to /usr/share/joe.
> Naturally, I prefer the standard $datadir/locale/ too, because if every
> project decides to add dozens of subdirectories for translation, then the
> system would end up with thousands of subdirectories (instead of dozens).
$datadir/locale/{lang}/LC_MESSAGES is the place for GNU gettext .mo files.
If joe uses this format then they should be put here. However, if joe uses
its own method (e.g. run-time parsing .po files) then a different place
(joe's private area) is better.
--
Egmont
|
|
From: Koblinger E. <eg...@uh...> - 2006-05-30 18:59:05
|
On Tue, May 30, 2006 at 10:18:51AM -0400, Joseph H Allen wrote:
> Also, GNU-gettext() would have you include the gettext() code along with
> each package, in the intl/ directory.
Really? I don't think so. I guess this dir is only necessary to provide
gettext on systems that don't support it. And on these systems it's okay for
me if joe uses an own implementation instead.
I don't know much about this autoconf/automake/libtool/libintl/etc... stuff,
but I've already written several apps for Linux: just a few #include's and
probably a #define _ gettext, and then you can write _("foo") and it works
perfectly. No need for bundled code at all.
--
Egmont
|
|
From: Sebastien K. <seb...@ko...> - 2006-05-31 08:46:22
|
On 5/24/06, Joseph H Allen <jh...@th...> wrote: > Update your sandbox (cvs update -d .). Also rerun the automake and autoconf > tools. I still can't compile the last CVS version... % automake aclocal.m4: 353: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER' aclocal.m4: 531: `jm_MAINTAINER_MODE' is obsolete; use `AM_MAINTAINER_MODE' automake: configure.ac: `PACKAGE' not defined in `configure.ac' automake: configure.ac: `VERSION' not defined in `configure.ac' configure.ac: 353: required file `./$@)].in' not found autoconf and ./configure run without error, but later: % make /bin/sh: -c: line 1: syntax error near unexpected token `)' /bin/sh: -c: line 1: `if test ! -f )].in; then rm -f ./stamp-h2.in; make ./stamp-h2.in; else :; fi' make: *** [)].in] Error 2 Anyway, I started the french translation by a copy of joe.pot to fr.po and I have a question: In english, boolean question are answered by (Y)es or (N)o, but in other languages, it's others words. In french it's (O)ui or (N)on. GNU Tools use current locale to allow more than one answer. For example in french, rm -i allow to answer both 'y' and 'o' to say Yes: % touch T % LC_ALL=C rm -i T rm: remove regular empty file `T'? o % ls T T % LC_ALL=fr_FR rm -i T rm: remove regular empty file `T'? o % ls T ls: T: No such file or directory Does joe have anything to use locale answer to thoses questions? Should I translate (y,n,^C) to (o,n,^C)? -- Seb, autocuiseur |
|
From: Sebastien K. <se...@ko...> - 2006-05-31 12:06:32
|
On Wed, May 31, 2006 at 10:46:19AM +0200, Sebastien Koechlin wrote: > I still can't compile the last CVS version... > > % automake > aclocal.m4: 353: `automake requires `AM_CONFIG_HEADER', not > `AC_CONFIG_HEADER' I upgraded automake from 1.4 (Debian/3.1) to 1.9.5 and it's fine now, I can build joe. Sorry for disturbing. -- Seb, autocuiseur |
|
From: Joseph H A. <jhallen@TheWorld.com> - 2006-05-31 13:00:23
|
"Sebastien Koechlin" <seb...@ko...> wrote: >Anyway, I started the french translation by a copy of joe.pot to fr.po >and I have a question: In english, boolean question are answered by >(Y)es or (N)o, but in other languages, it's others words. In french >it's (O)ui or (N)on. >GNU Tools use current locale to allow more than one answer. For >example in french, rm -i allow to answer both 'y' and 'o' to say Yes: >% touch T >% LC_ALL=C rm -i T >rm: remove regular empty file `T'? o >% ls T >T >% LC_ALL=fr_FR rm -i T >rm: remove regular empty file `T'? o >% ls T >ls: T: No such file or directory >Does joe have anything to use locale answer to thoses questions? >Should I translate (y,n,^C) to (o,n,^C)? 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. I'm curious how they support UTF-8 for this. Joe |
|
From: Koblinger E. <eg...@uh...> - 2006-05-31 14:16:44
|
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 ;) -- Egmont |
|
From: Sebastien K. <se...@ko...> - 2006-05-23 17:14:00
|
On Mon, May 22, 2006 at 04:13:59PM -0400, Joseph H Allen wrote: > There's now a fake 'de.po' file in the po directory. The infrastructure > appears to be working: if I type 'LANG=de_DE joe sdfdsf', it says > "New File 1" instead of "New File". I tried to start a french translation (as I use joe since about 1994), but I hava an error when compiling it. I grab fresh sources from CVS, run ./configure --with-included-gettext or just ./configure but I have the following error (problem with substitution?): % make make all-recursive make[1]: Entering directory `/home/seb/joe-editor.src/joe-current' Making all in po make[2]: Entering directory `/home/seb/joe-editor.src/joe-current/po' make[2]: *** No rule to make target `@POMAKEFILEDEPS@', needed by `Makefile'. Stop. make[2]: Leaving directory `/home/seb/joe-editor.src/joe-current/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/seb/joe-editor.src/joe-current' make: *** [all] Error 2 % uname -smro Linux 2.6.12.6-xen i686 GNU/Linux I deleted the dependency in po/Makefile to compile. Is someone already working on a french translation? -- Sebastien Koechlin |
Thanks for helping keep SourceForge clean.
X