Re: [translations] Our language downloads are chaotic.

[David Kastrup]

Federico Bruni <address@hidden> writes:

> Il giorno gio 27 feb 2020 alle 16:17, David Kastrup <address@hidden> ha
> scritto:

>> 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).

Ok, yes.  The Apache documentation talks about html extensions.

> 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.

Yes.  And it would appear that the masslink scripts fill in nodes from
English that would otherwise be missing.  If they do that on the webpage
material as well (I really don't have a clue which of make/* and
stepmake/* is relevant for what), the fallback of a requested language
should always be to English.

>> 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/

Some time ago.

>> 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.

I am not sure whether there will be no conflict if someone whose browser
settings specify his preference for Italian tries to read the English
documentation.  Wouldn't the server then replace the non-extension links
with Italian ones?  Or does that only happen for non-existing files?

>> 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.

That has the disadvantage of somebody who has Czech as his first
language and German as his second in the browser.  Non-existing Czech
pages would then fall back straight to English.  But if they get an
"explicitly" German page, following any links in there would lead to
German documentation even if Czech were available.

I am not sure we can reliably do better.

-- 
David Kastrup