Re: Potential improvements to the homepage?

[Federico Bruni]

Il giorno mer 16 nov 2016 alle 21:07, Flaming Hakama by Elaine 
<address@hidden> ha scritto:
> Some comments in response to the most recent (but not quite actually 
> recent)  iteration of the perennial web site discussion.
>
>
>
> State of Translation
>
> Looking at the translated versions of the website, most of the 
> content from the homepage isn't actually translated, but remains in 
> English.

This is not accurate. Most up-to-date translations have all content 
translated except the pondings:
http://lilypond.org/index.it.html
http://lilypond.org/index.fr.html
http://lilypond.org/index.ja.html
http://lilypond.org/index.de.html (even though german is not really 
maintained at the moment)


> Even within the translated versions, the links within there quickly 
> revert to English:  For example, on the French site 
> http://lilypond.org/essay.fr.html, I click through to "Essai (HTML 
> multipages): manuel sous forme de plusieurs pages HTML – chaque 
> page est assez petite." 
> http://lilypond.org/doc/v2.18/Documentation/essay/index.fr.html.   
> From there, when I click on a subheading in the left column, I get 
> english: "1.1 L’histoire de LilyPond" brings me to Engish page "The 
> Lilypond Story" 
> http://lilypond.org/doc/v2.18/Documentation/essay/the-lilypond-story

This is a known problem. Read from here:
https://sourceforge.net/p/testlilyissues/issues/2273/#3b1d
> So, I'm not convinced that our current infrastructure actually meets 
> reasonable requirements for internationalization.  This despite the 
> factd that the amount of language support we have is both surprising 
> and impressive.
>
> Given that various people on this list recently complained about an 
> LSR snippet with German variable names, pointing out that English is 
> almost a neccessary evil when using lilypond, it makes me wonder how 
> useful are the non-english websites?  Are we just setting up 
> non-English speakers for failure by making it seem like they can get 
> along in their language?

I met some italian users who thanked me a lot for translating website 
and documentation.
In Italy there are still people who can't read english fluently. OTOH I 
don't think that e.g. any Scandinavian user will ever need the 
documentation in his language.

> If I understand correctly, the website content is (or could easily) 
> also be produced as PDF?  If so, then in the worst case, the 
> translated websites could point to the PDF documentation for that 
> language.
>
> Given the amount of content in the existing translation 
> infrastructure, it seems like we should absolutely keep it available 
> in some fashion.

Are you proposing to remove unmaintained translations but keeping a 
link to the PDF of the translated website (even if out-of-date)?

I have other ideas.
The first would be adding a warning for untranslated/out-of-date pages, 
like the one used on FSFE website:
https://fsfe.org/activities/policy/eu/policy-goals/privacy.it.html 
(untranslated)
https://fsfe.org/contribute/internship.it.html (not up-to-date)

This should be not too difficult to add in the current infrastructure. 
At least for someone who knows Python.

Another possibility would be switching _the website only_ (not the 
entire documentation) to gettext.
I've read some Gnome documentation, where out-of-date paragraphs are 
replaced by the original english text. This may make the text 
"bilingual" but the contents would be kind of up-to-date.

> If it is a possibility to develop a much better site experience, and 
> not have 100% of the content translated, is that an acceptable 
> trade-off?  Or is it more important to have language parity than it 
> is to have a overall better site in English?

I don't see the link between the two goals.
Please be more specific.

> CMS
>
> In most cases, the choice of a CMS should be based on who is going to 
> maintain the content.
>
> One benefit of the current approach is that only "the usual suspects" 
> can maintain it.
> One drawaback of the current approach is that only "the usual 
> suspects" can maintain it.
>
> One benefit of using a CMS like Wordpress is that people other than 
> "the usual suspects" can maintain it.
> One drawaback of using a CMS like Wordpress is that people other than 
> "the usual suspects" can maintain it.
>
> In short, we need to figure out what website content we want and who 
> should produce it (in terms of what skills they do or do not possess) 
> before any reasonable decisions can be made as to a technology stack.
>
>
> In general Wordpress is the current standard in website deployment.  
> According to data from this year at 
> https://w3techs.com/technologies/details/cm-wordpress/all/all, 
> "WordPress is used by 59.2% of all the websites whose content 
> management system we know. This is 26.6% of all websites."  It has 
> more market share than all other CMSs put together, although still 
> less than "no CMS", which is the majority.
>
> It is a safe bet to say that the future of Wordpress is much more 
> rosy than the future of lilypond.  There are probably 1000X more 
> developers fluent in Wordpress just in the SF bay area than there are 
> developers fluent in lilypond in the entire world.  There is very 
> little chance that a site built using Wordpress will become 
> un-maintainable in our lifetimes.  By "maintain", I mean both the 
> content as well as the platform code and plugins that produce/manage 
> the pages and site administration.
>
> All this to say that, if any CMS should be considered besides or in 
> addition to the current setup, Wordpress is the only reasonable CMS 
> to consider.

I don't think that CMS is an option to consider. I don't have time to 
rediscuss this again, sorry. You find the opinions on this subject in 
the archives.

But I agree with you in one point: it's probably easier rewriting the 
website from scratch, using a modern and web developer friendly tool (a 
static site generator IMO), than improving the current infrastructure, 
which has long standing bugs and limitations.