Re: [translations] Our language downloads are chaotic.

[David Kastrup <dak@xxxxxxx>]

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.

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.

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.

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.

So to make this work in a best-of-all scenario, we'd need
language-specific subdirectories where all languages are present in each
language-specific subdirectory, but with the dedicated language only
linking to files with its dedicated extension and all other languages
linking to files with the non-dedicated name.

This.  is.  a.  nightmare.

If we don't want to drown in duplication, I think we'll keep with one
directory but explicit links.  That means that if you get a German
substitution page for a missing Czech page and use links within it, they
will always lead to German pages even if a corresponding Czech page
would be available.

Or we have two top-level directories: one driven by browser preference,
one hardlocked to selected languages, and using some
"give-me-language-x" link anywhere in the documentation leads you to the
hardlocked variant which cannot heed browser preferences.  Probably just
a matter of a different .htaccess file?

But for now, I think the "stick-with-one-language-if-node-exists"
version best.  It will mean that when new translated nodes appear, links
to them will need to get (manually?) changed from "generic" to
"language-specific".

And we'll want .en versions of all files that are hardwired to stick in
the .en universe, or English will be the least persistent language of
all.

Does anybody have a better idea than that?

-- 
David Kastrup