Re: localized URLs

[Bruno Haible]

Hi Akim,

> Before (so translations from from bison's fr.po):
> 
> Aide générique sur l'utilisation des logiciels GNU: 
> <http://www.gnu.org/help/gethelp.fr.html>.
> 
> After (translations from gnulib-po's fr.po, but the URL is not localizable):
> 
> Aide globale sur les logiciels GNU : <https://www.gnu.org/gethelp/>

Good point. Yes, you are right, gettext or gnulib should provide a way to deal
with localized URLs.

Like with localized strings in PO files, we are merely looking for a
string -> string replacement that is localizable.

However, it would be silly to put the burden of this localization on the
translators, when in fact it can be done (and updated) by the package
maintainer easily.

I'm thinking at a small program (shell script) that can be invoked as

  gen-localized-url IDENTIFIER DEFAULT-URL PATTERN

where PATTERN may contain format directives such as
  %ll-%cc
  %ll_%CC

This program will try the PATTERN for all possible languages and emit a
set of PO files of the form

  msgid "https://www.gnu.org/gethelp/";
  msgstr "http://www.gnu.org/help/gethelp.fr.html";

into a subdirectory. The package maintainer can then use dcgettext(),
and rerun the gen-localized-url command once a year, to capture newly
arrived translations.

This consideration proves that translator involvement is not necessary.

Now, this way of doing things is heavy from the packaging point of view:
Most developers won't like the idea to have 2 x 10 additional .mo files
to be installed with their package. Especially since the concept of PO and
MO files was conceived for translators, and translators are not involved
here.

A possible optimization would be to let the

  gen-localized-url IDENTIFIER DEFAULT-URL PATTERN

command emit a .h file that looks like this:

===============================================================================
#include "localized-url.h"

/*
 * List of localizations of <https://www.gnu.org/software/gethelp.html>.
 * This file is in the public domain.
 */

static const char * const IDENTIFIER_translations =
  {
    "en",
    "cs",
    "de",
    "es",
    "fr",
    "ja",
    "ro",
    "ru",
    "sq",
    "zh_CN",
    NULL
  };

static localized_url_t const IDENTIFIER =
  {
    "https://www.gnu.org/software/gethelp.html";,
    "https://www.gnu.org/software/gethelp.%ll-%cc.html";,
    IDENTIFIER_translations
  };
===============================================================================

where localized-url.h essentially contains the type definition

typedef struct
  {
    const char * default_url;
    const char * pattern;
    const char * const * translations;
  }
localized_url_t;

This would be a much more compact way to represent the set of localizations
of a URL.

The problem that I see here is that in order to fetch the appropriate URL,
the runtime code must access
  gl_locale_name (LC_MESSAGES, "LC_MESSAGES")
or - using functions defined in dcigettext.c -
  get_category_value (LC_MESSAGES, "LC_MESSAGES").

gl_locale_name has the drawback that it requires a large bunch of code from
gnulib. (100 KB of source code, but only 1 KB of binary code on glibc systems.)

get_category_value has the drawback that it is not exported from glibc
and libintl.

So, this optimized representation of localized URLs requires some prior work
in gettext, if we don't want gl_locale_name.

Or maybe you have better ideas to solve this dilemma?

Bruno