Re: localized URLs

[Akim Demaille]

Hi Bruno,

> Le 28 mai 2019 à 00:07, Bruno Haible <address@hidden> a écrit :
> 
> Hi Akim,
> [...]
> Or maybe you have better ideas to solve this dilemma?

I would certainly not claim to have better ideas :)

You are looking for a generic way to deal with URLs that have alternatives for 
languages.  I was looking only at the problem at hand, that is to say gnulib's 
version-etc module.

I personally do not see much of a problem to have the translators specify the 
URLs themselves.  For instance in Bison we have:

Report translation bugs to <http://translationproject.org/team/>.

that becomes

po/ca.po-"Informa dels errors de traducció a 
<http://translationproject.org/team/ca.";
po/ca.po-"html>.\n"

but also

po/da.po-msgstr "Rapporter oversættelsesfejl til <address@hidden>.\n"

or

po/fi.po-"Ilmoita käännösvirheistä osoitteeseen <address@hidden"
po/fi.po-"net>.\n"

or

po/nl.po-msgstr "Meld fouten in de vertaling aan <address@hidden>.\n"

po/pl.po-"O błędach tłumaczenia poinformuj <address@hidden"
po/pl.po-"net>.\n"

etc.


Of course, this very case is kind of special, agreed.  But still, I don't think 
errors in URL translations are more serious that plain errors in the 
translations (I fixed some of them in my own language that were even conveying 
incorrect semantics), or delicate pieces of text such as the GPL disclaimer 
excerpt.

For the general case, I suppose you can't even expect the pattern to be always 
the language code appearing somewhere.

Anyway, if we focus on version-etc, gnulib could easily provide the 
correspondance for the main URLs of the FSF, e.g., as a C function.  
Alternatively it could even bake them into gnulib-po, which would also avoid 
having to deal with yet another po dir, but still benefit from the Gettext 
ecosystem.

On the other end, it would be nice if the FSF supported something like 
'?locale=CODE' or '?lang=CODE', as some sites do, as it would relieve us from 
having to maintain some correspondance by hand.

Cheers!