[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: localized URLs
Re: localized URLs
Tue, 28 May 2019 08:44:07 +0200
> 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
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/>.
po/ca.po-"Informa dels errors de traducció a
po/da.po-msgstr "Rapporter oversættelsesfejl til <address@hidden>.\n"
po/fi.po-"Ilmoita käännösvirheistä osoitteeseen <address@hidden"
po/nl.po-msgstr "Meld fouten in de vertaling aan <address@hidden>.\n"
po/pl.po-"O błędach tłumaczenia poinformuj <address@hidden"
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
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
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.