Hi Bruno, > Le 28 mai 2019 à 00:07, Bruno Haible <br...@clisp.org> 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 <da...@dansk-gruppen.dk>.\n" or po/fi.po-"Ilmoita käännösvirheistä osoitteeseen <translation-team-fi@lists.sourceforge." po/fi.po-"net>.\n" or po/nl.po-msgstr "Meld fouten in de vertaling aan <vertal...@vrijschrift.org>.\n" po/pl.po-"O błędach tłumaczenia poinformuj <translation-team-pl@lists.sourceforge." 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!
