Re: [translations] Our language downloads are chaotic. |
[ Thread Index |
Date Index
| More lilynet.net/translations Archives
]
- To: David Kastrup <dak@xxxxxxx>
- Subject: Re: [translations] Our language downloads are chaotic.
- From: Federico Bruni <fede@xxxxxxxxxxxxx>
- Date: Fri, 28 Feb 2020 13:01:31 +0100
- Cc: lilypond-devel@xxxxxxx, translations@xxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1582891458; bh=MCbzaFIFDtnOH+w+nEvfQjxtFbUaSxmKOTGuY4It4Bo=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=QvF7fEkcR7P2C8o+S9ONZsZaSpDvgRrNVJ+2j4NZV2fgTcJzG7BMd8qmuK1w9ZP6G m+0MQ46Xy0wGlVW+7eOSaCYL1Q58S/Bl6pTJcSrjfPvth6b9zbC+ARbfVIJsVX6tHx Lk4zcwtHVtOG/ZgKNAZXPmtH6jaAn6Q9ruKX/aac=
Il giorno gio 27 feb 2020 alle 16:17, David Kastrup <dak@xxxxxxx> ha
scritto:
Federico Bruni <fede@xxxxxxxxxxxxx> writes:
Il giorno gio 27 feb 2020 alle 02:10, David Kastrup <dak@xxxxxxx> ha
scritto:
For example, try downloading any French documentation from
<http://lilypond.org/doc/v2.19/Documentation/web/notation.fr.html>
if
your browser locale is not French. Possibly even if it is.
I am currently setting up the size listings to correspond with the
actual files linked there, but the actual files apparently are
incorrect
all too often.
I've not yet discovered a coherent strategy in the various
translations
how they attempt to, by and large, get a hold of downloads in their
own
language.
The download details pages are where the sizes are currently given
(the
others are without size currently as far as I can tell: it should
not be
too much work to reorganise size indications once I am finished, to
get
more of them).
I see that the link to the PDF file is correct in the spanish page:
http://lilypond.org/doc/v2.19/Documentation/web/notation.es.html
So it seems that the other languages should be fixed.
I don't know where though.
The files are present, for example:
http://lilypond.org/doc/v2.19/Documentation/notation.it.pdf
it's only a wrong URL.
The links in the website generated by make doc are correct, as you
can
see if you open a locally built website.
The thing is a nightmare to diagnose since our web server settings
tell
the server to serve xxx.it.extension in preference of xxx.extension if
your browser settings say that you prefer Italian.
So when a link in the Italian documentation demands xxx.extension, a
developer having Italian set as preference in their browser will see
xxx.it.extension and think things work well. But there are two
problems
with that: if somebody without Italian in their preferences tries the
Italian language version, they get thrown back all the time at a
different language (English, or their own preferred language). And if
they download a PDF file, it will be named notation.pdf but correspond
to notation.it.pdf.
AFAICS your reasoning is correct for HTML links, but not for links to
other types of files (such as PDF files).
Take this page as example:
http://lilypond.org/doc/v2.19/Documentation/web/notation.it.html
The link to the notation PDF file is a direct link. Content negotiation
doesn't play any role here.
http://lilypond.org/doc/v2.19/Documentation/notation.pdf
This means that we must fix the link.
Catalan and spanish pages are the only languages which link to the
translated PDF file:
http://lilypond.org/doc/v2.19/Documentation/web/notation.ca.html links
to notation.ca.pdf
http://lilypond.org/doc/v2.19/Documentation/web/notation.es.html links
to notation.es.pdf
The link for content negotiation is:
http://lilypond.org/doc/v2.19/Documentation/web/notation
and will resolve to the HTML file of the browser language.
There's no link for PDF file content negotiation, at least in this
setup.
So I think the proper thing to do would be to rely on automatic
language
selection _only_ for the landing page(s) of the LilyPond web site and
use explicit language links for everything we do.
I agree. This has been already proposed in issue 2273:
https://sourceforge.net/p/testlilyissues/issues/2273/
Which means that we'll likely need to generate/link xxx.en.extension
versions as well so that the English documentation, once selected,
manages to stick with English.
I don't see the reason for using xxx.en.extension.
If 2273 is fixed, localized pages will have xxx.LANG.html links while
english pages will have simply xxx.html, as it happens with offline
website. There's no possible conflict.
There is the odd case of untranslated pages that should fall back to
browser defaulted substitution languages. Those would be reasonable
candidates for getting called with non-explicit extensions.
But then anything linked from within them would again be a candidate
for
using non-explicit extensions.
Untranslated pages are currently generated from english sources. So
there's a file "duplication": two equal xxx.html and xxx.LANG.html
files. No need to fallback then.