lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New LilyPond website


From: David Kastrup
Subject: Re: New LilyPond website
Date: Tue, 29 Nov 2016 12:42:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Johan Vromans <address@hidden> writes:

> On Tue, 29 Nov 2016 10:38:32 +0100 (CET), Werner LEMBERG <address@hidden> 
> wrote:
>
>> As David K. pointed out,
>> it must be viewable and navigatable by blind people.
>
> As I wrote, there are some aspects that need to be solved. I just do not
> reject a potential valuable approach beforehand.
>
>> Additionally, it
>> must be possible to build the documentation of lilypond with `make
>> doc'.
>
> As discussed, this can be solved by separating the site and the
> documentation. 

Which means that the translators are no longer integrated into the
translation workflow for the site.

Who is going to pick up the slack?

>> We then would need someone who is doing the job to set this up and
>> convert the old stuff to the new one.  However, this isn't a trivial
>> task and it probably takes a long time to get it right, so we need
>> someone who has a lot of endurance and stamina...
>
> In other words, it will never happen.
>
> OTOH:
> 1. move the current site to lilypond-classic

Different domain?

> 2. move John's site in place
> 3. add a textline at the top to point visual impaired people to the classic
> site

What about translations?

I really don't see the point in moving a draft into production position
if we don't have a view on how the problems are going to be addressed in
future.  For better or worse, most long-term maintenance ends up in
always the same hands, so fly-by changes tend to have a lot of
repercussions.  Without a view on how to address in the long run, we are
likely to end up worse than before.  It's not like this hasn't happened
previously and it's not like we haven't had this discussion lots of
times before.

The current setup is not fancy, but maintaining it is integrated into
our documentation maintenance and thus kept up as well as our general
translation process (which has a few really well supported languages and
several less well supported languages and further spreading out the
required skill set is not likely to improve the likelihood of
improvement for the worse supported languages).

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]