Re: Bug#53981: language-chooser
Hi.
In article <[🔎] 20000104135223.A19516@artica.id-agora.net>,
at Tue, 4 Jan 2000 13:52:24 +0000,
on Re: Bug#53981: language-chooser,
Enrique Zanardi <ezanardi@id-agora.com> writes:
> The problem is two folded.
>
> If we are trying to load an obsolete trm file (one generated from a
> different version of dbootstrap, with more or less _("strings") )
> dbootstrap must display an error message and stop (I posted a patch on
> debian-boot a few weeks ago to do just that).
>
> The translated string is searched by its position on the trm file (not by
> its non-translated counterpart as it is in gettext) so, if there's a
> different number of strings on the trm file than expected, there's no way
> to tell which one goes where (and usually some of them won't be there,
> NULL pointer, so the segfaults).
>
> Using the original string to search for the translated string means
> including the original strings on the executable and on all the trm
> files, as gettext does, defeating the whole purpose of using pointerize.
Here is the patch for pointerize-0.3/lib/loadtrm.c, which enables
the fall back to C.trm file on error in opening the specified trm file.
--- build/pointerize-0.3/lib/loadtrm.c Sat Mar 6 21:33:45 1999
+++ buildchk/pointerize-0.3.1/lib/loadtrm.c Thu Jan 13 20:03:34 2000
@@ -27,6 +27,9 @@
#include <unistd.h>
#include <sys/mman.h>
+#include <string.h>
+#include <sys/param.h>
+
/* The following is copied from gettext.h */
/* BEGIN gettext */
@@ -64,7 +67,7 @@
/* Load the message catalogs specified by FILENAME. On error return 0,
* on success return the nuber of strings read. */
-int load_trmfile (char *file, char **messages_table, int tstrings) {
+int load_trmfile_0 (char *file, char **messages_table, int tstrings) {
int fd, cnt;
size_t size;
struct stat st;
@@ -105,3 +108,32 @@
messages_table[cnt]=(char *)data+(*ptr);
return cnt;
}
+
+/* Load the message catalogs specified by FILENAME.
+ * On error, then try the C.trm file which is located
+ * in the same location as well as the specified file */
+int load_trmfile (char *file, char **messages_table, int tstrings) {
+ int ret;
+ char *chrp;
+ char cfile[PATH_MAX];
+
+ /* First, open the specified file */
+ if ( (ret = load_trmfile_0 (file, messages_table, tstrings)) != 0) {
+ return ret;
+ }
+
+ /* If error, then try to C.trm file */
+ strncpy(cfile, file, PATH_MAX);
+ cfile[PATH_MAX -1] = '\0';
+ if ((chrp = rindex(cfile, (int)'/')) == NULL) {
+ strcpy(cfile, "C.trm");
+ } else {
+ *(++chrp) = '\0';
+ if( (int)(chrp - cfile) >= (PATH_MAX - 4)) {
+ return 0;
+ }
+ strcat(cfile, "C.trm");
+ }
+ return load_trmfile_0 (cfile, messages_table, tstrings);
+}
+
Sure, this is not smart as gettext does, but it may work IMHO.
If we can use mixed message from translated and original one,
it may be better, but this "using original (C) as the whole on error"
approach will be better than stoping dbootstrap on error.
> Now for the second fold:
>
> Sometimes a trm file is generated from an up-to-date ("msgmerged")
> but not fully translated LANG.po file. "msgfmt" (another gettext tool)
> doesn't write on the LANG.mo file messages that haven't been translated
> (or that are marked as "fuzzy") and so the LANG.trm file generated from
> that LANG.mo file will be treated by dbootstrap as if it were obsolete.
>
> That's what I was going to fix (and haven't done yet) by making trim-mo
> put the non-translated string (instead of the translated one) on the
> LANG.trm file when the translated string is not on the LANG.mo file
> (probably because that message hasn't been translated yet, or is marked as
> "fuzzy"). That means rewriting trim-mo, as currently it just extracts
> the translated strings from the LANG.mo file, and doesn't use any other
> file. The new trim-mo will have to use both C.mo and LANG.mo or go one
> step higher and parse LANG.po like msgfmt does.
I think using LANG.po is the best way. If genheader and trim-mo can be
merged, and if pointerize and them can be modified to use LANG.po,
(i.e. no need for LANG.mo anymore) it will be better.
> I'll fix pointerize as I said above, but that doesn't prevent someone
> trying to use an obsolete trm file. The language chooser should use a
> check-trm-file routine to detect invalid/obsolete trm files before
> displaying its menu, so that only valid files are offered to the user.
How this check can be done ? I think the trm file does not have the header
info to detect invalid/obsolete trm files,,,
If only the number of the strings can be used, then I think this
proposal of "fall back to C.trm" approach will work. Anyway, this problem
will end when all the translation work is done.
Regards.
--
Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>
Reply to: