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. 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 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? 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. 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? 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. However, this is not necessarily an all-or-nothing proposition. It is possible to import or reference the existing site(s) within a Wordpress site, so that "the ususal suspects" can continue to produce the existing documentation, and it just rolls into the CMS. In addition, people who are not "the usual suspects" can contribute additional content that exists only on the website (and is not translated, produced in PDF, etc.) HTML/CSS I can't speak to the texinfo stack that produces this HTML, as to how easy it is to maintain. Looking at that actual markup on the site, it is semantically good, such that anyone interested in re-skinning the site would have a fairly easy time. The issues I see are extremely minor, such as the presence of quite a number of empty links. There are perhaps an excessive use of ids and classes on elements. (Excessive both in terms of not adding any useful semantic information, and not being used for styling or scripting, such as the class="subheading" on H3 tags.) Reskinning For the purposes of experimentation, this can be done without any intervention from anyone at all: 1. Create a stylesheet and publish it anywhere. You will need URL for the CSS file, which can be on any web site, or a locally running server). (This doesn't seem to work with local file:/// references.) 2. Create a bookmark in your browser 3. Edit the bookmark URL to this: javascript: (function () { var styles = document.createElement('link'); styles.rel = 'stylesheet'; styles.href = ' http://www.awwwards.com/bundles/tvweb/css/main.css'; document.getElementsByTagName('head')[0].appendChild(styles); })(); In this case, I grabbed a stylesheet from a random portfolio site. You would replace it with the URL for your stylesheet. 4. Visit a page of the lilypond site http://lilypond.org 5. Visit/click the bookmark 6. See the site transformed in layout David Elaine Alt 415 . 341 .4954 "Confusion is highly underrated" ela...@flaminghakama.com self-immolation.info skype: flaming_hakama Producer ~ Composer ~ Instrumentalist -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
