Menu
▾
▴
#2273 Translations: Links in the online manuals should point to the appropriate language if available
Originally created by: *anonymous
Originally created by: pkx1...@gmail.com
On http://lilypond.org/doc/v2.14/Documentation/learning/index.nl.html there is a link '1. Leerboek' in the table of contents pointing to
http://lilypond.org/doc/v2.14/Documentation/learning/tutorial
which with a browser-preferred language of English leads the webserver to serve up
http://lilypond.org/doc/v2.14/Documentation/learning/tutorial.html
allthough there IS a localized Dutch page for this link-target:
http://lilypond.org/doc/v2.14/Documentation/learning/tutorial.nl.html
The webserver is doing it's job in serving up the 'preferred language'-version of the requested source, but being explicitly on the Dutch-language version of the Documentation I would expect the links to make my browser explicitly request the Dutch-language version of the resource whenever available.
Regards,
Hans
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Summary: Translations: Links in the translated documentation should point to the appropriate language if available
Originally posted by: paconet....@gmail.com
The report is self-explanatory on what should we do to fix the issue. We should build the html docs so that every link contains the suffix of the current language, instead of no suffix at all.
Originally posted by: fedel...@gmail.com
It seems it's been fixed in last version (2.15.43)?!?
Look here: http://grenouille.lilynet.net/lilypond-web/translation/Documentation/notation/index.fr.html
The link on the left menu have all the .fr extension.
The same occurs for any other language: all of them have their own lang suffix.
Originally posted by: fedel...@gmail.com
Issue 2633 has been merged into this issue.
Related
Issues:
#2633Originally posted by: fedel...@gmail.com
Regarding comment 3, I realize now that this problem affects only the online documentation.
Offline documentation (build with 'make doc') already as the language suffix in the links.
So it's worth specifying that the issue is related to 'make website'. I'm changing the title of the issue accordingly.
Offline manuals can afford to have suffixed links, because the untranslated files are duplicated from the english file (local hard disk is cheap).
Manuals to be uploaded to the server cannot afford such waste of space (except lilynet, apparently :-)). Therefore we need some clever script which creates "suffixed links" only if that node has been actually translated.
I got it right?
Or there's any other reason for removing the suffix on online manuals?
Summary: Translations: Links in the online manuals should point to the appropriate language if available
Originally posted by: fedel...@gmail.com
I've just realized I've told another stupid thing.
The files are duplicated also on the server. For example, this is an untranslated node but the file is there:
http://lilypond.org/doc/v2.17/Documentation/notation/input-structure.it.html
So it's just a matter of building the website in a similar way the offline documentation is built.
Originally posted by: fedel...@gmail.com
BTW, I just found out something annoying about the missing suffixes in the online manuals.
The deep links (i.e. links to specific points in a page) in the index of manuals won't work if your browser user-agent is set to a language different from english, so you get redirected to the section and you lose the "jump to" feature.
See for example:
http://lilypond.org/doc/v2.17/Documentation/usage/latex#index-_005cheader-in-LaTeX-documents
if you have a browser with a language different from english, of course
Originally posted by: paconet....@gmail.com
Just adding a little more info to the subject.
I think the latter is not caused by missing suffixes. The deep target does not exist either with or without the suffix in URL. An anchor should exist in untranslated form. Instead, in-page anchors are translated.
Therefore, to sum up, links with(out) suffixes with English anchors do not link correctly, in pages with(out) suffixes in URL, to translated anchors.
Originally posted by: fedel...@gmail.com
I think that Type:Build is more appropriate here
Labels: -Type-Documentation Type-Build
Originally posted by: goo...@ptoye.com
I've had a similar problem when saving the downloaded web page locally with Firefox - the links in the TOC frame are saved as links to the server, while links in the contents at the top of the main page as saved as local links. This seems inconsistent to me, and maybe should be looked at.
I'm using an English browser - no idea what happens in Italian..
Pages saved with Opera and IE don't download the files at all - the links all point back to the server, which rather negates the reason for saving the page (to save browsing time when the Internet's being slow).
Diff: