:04, Colin Campbell escribió:
It happens that there are a couple of MRs in the queue, which deal
with translated parts of the documentation. That caused me to wonder
whether we have someone in overall charge of translation. I see that
we list Francisco Vila as Translation Meister, but I can'
It happens that there are a couple of MRs in the queue, which deal with
translated parts of the documentation. That caused me to wonder whether
we have someone in overall charge of translation. I see that we list
Francisco Vila as Translation Meister, but I can't find contact info for
Le 06/11/2022 à 14:57, Jean-Charles Malahieude a écrit :
I would then adapt CG-5.9.3 to state that the ID to pick *must be* the
latest on master, before any update and commit.
Sounds sensible, do you intend to open an MR for that?
Best,
Jean
OpenPGP_signature
Description: OpenPGP digital s
ause of what you say below, it happens to have been a /bad/ habit…
Our workflow is based on rebasing one's branch just before merging, and
rebasing changes commit IDs (more precisely, because Git commits are
immutable, it creates new commits with different IDs).
In the old times the Tr
Le 05/11/2022 à 17:26, Jean-Charles Malahieude a écrit :
Le 03/11/2022 à 21:31, Jean Abou Samra a écrit :
Hi Jean-Charles,
What is your procedure for filling in commit IDs in translated
files? It looks like a number of them don't exist in the repository.
I either copy what is returned by
Le 03/11/2022 à 21:31, Jean Abou Samra a écrit :
Hi Jean-Charles,
What is your procedure for filling in commit IDs in translated
files? It looks like a number of them don't exist in the repository.
I either copy what is returned by "git rev-parse HEAD" or then content
of the "Id SHA1" field
Hi Jean-Charles,
What is your procedure for filling in commit IDs in translated
files? It looks like a number of them don't exist in the repository.
~/repos/lilypond $ for commit in $(git grep -hPo --no-line-number
"(?<=Translation of GIT committish: ).*" -- Documentation/f
Le 04/09/2022 à 21:41, Jonas Hahnfeld via Discussions on LilyPond
development a écrit :
Hi all,
when updating authors.texi for
https://gitlab.com/lilypond/lilypond/-/merge_requests/1609 I noticed
that I forgot to run translation-status for almost a year now. I've
included it in the
Hi all,
when updating authors.texi for
https://gitlab.com/lilypond/lilypond/-/merge_requests/1609 I noticed
that I forgot to run translation-status for almost a year now. I've
included it in the merge request, but then noticed that the file doc-
translation-list.itexi wasn't updating
On Jul 19, 2022, at 18:46, Jean Abou Samra wrote:
>
> Then we have the style of solution found in !1451, with per-engraver
> heuristics. I honestly dislike this. I don't want to sound harsh, but
"\fine does not end iteration"
https://gitlab.com/lilypond/lilypond/-/merge_requests/1496
—
Dan
s
similarly with \repeat volta and \repeat segno.
That said, it's not that I really care all that much about the syntax.
Above all, I would like to avoid adding logic to all/many unrelated
engravers.
PS: thinking again about this
After all, it might be the only fully correct of doing it
On Jul 10, 2022, at 12:04, Jean Abou Samra wrote:
>
> The currently recommended syntax for DS al fine
> repeats is
>
> \repeat segno 2 {
> c'1 1 1 1
> \volta 2 \fine
> c'1 1 1 1
> }
>
> This seems to work just as well, though:
>
> \repeat segno 2 {
> c'1 1 1 1
> \volta 2 \fine
> \v
Le 09/07/2022 à 19:51, Jean Abou Samra a écrit :
Repeats are complicated and I didn’t give this much thought, so it might make
no sense, but you see the basic idea: \unfoldRepeats would be able to unfold
the music in a way that doesn’t need interrupting translation with an event in
the
> Le 9 juil. 2022 à 22:08, Dan Eble a écrit :
>
> Do you have any concern about other engravers might have acknowledged the
> grobs that are about to be killed, which might have performed interesting
> actions assuming that the grobs would continue to exist on one system or
> another? Does
Dan Eble writes:
> On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
>>
>> Instead of rearranging the translation process to let \fine abort
>> translation, let translation run normally until the end.
>>
>> Then, ‘cut’ the result.
> ...
>> For layou
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
>
> Instead of rearranging the translation process to let \fine abort
> translation, let translation run normally until the end.
>
> Then, ‘cut’ the result.
...
> For layout output, there is already a battle-tested algorithm,
music in a way that doesn’t need interrupting translation with an event in
the middle. In the above, which … an event at the point of fine was entered in
determines whether it is included at the unfolded end.
On Jul 9, 2022, at 11:56, Jean Abou Samra wrote:
>
> A third option: get out of this uncomfortable situation by
> changing the syntax (it hasn't made it to a stable release
> after all) so that which events are included and which
> are not is fully explicit in the ly code.
This idea is a bit vag
Le 09/07/2022 à 17:38, David Kastrup a écrit :
Unmatched events are a problem in MIDI. MIDI processors and sequencers
working with files may to some degree try to repair such problems,
partly because they need to do so when cutting and pasting regions as
well. But you don't get guarantees.
T
Jean Abou Samra writes:
> Le 09/07/2022 à 16:31, Dan Eble a écrit :
>> On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
>>> Then, ‘cut’ the result. For MIDI, that shouldn’t be too hard: while
>>> outputting, just stop where \fine was used.
>> For the events that are simultaneous with the \fine,
Le 09/07/2022 à 16:22, Dan Eble a écrit :
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
For example, whether an item on the non-musical column at the point of \fine is
included depends on whether its break-visibility makes it visible at EOL. The
fine text itself will thus be included, whil
On Jul 9, 2022, at 10:38, Jean Abou Samra wrote:
>
> Le 09/07/2022 à 16:31, Dan Eble a écrit :
>> On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
>>> Then, ‘cut’ the result. For MIDI, that shouldn’t be too hard: while
>>> outputting, just stop where \fine was used.
>> For the events that are s
Le 09/07/2022 à 16:31, Dan Eble a écrit :
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
Then, ‘cut’ the result. For MIDI, that shouldn’t be too hard: while outputting,
just stop where \fine was used.
For the events that are simultaneous with the \fine, would you emit them or not?
If you
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
>
> Then, ‘cut’ the result. For MIDI, that shouldn’t be too hard: while
> outputting, just stop where \fine was used.
For the events that are simultaneous with the \fine, would you emit them or not?
If you would emit them, then you would emit not
On Jul 8, 2022, at 13:39, Jean Abou Samra wrote:
> For example, whether an item on the non-musical column at the point of \fine
> is included depends on whether its break-visibility makes it visible at EOL.
> The fine text itself will thus be included, while a rehearsal mark won’t.
> That is ju
> Le 5 juil. 2022 à 08:11, Jean Abou Samra a écrit :
>
> Neither am I, but it is the only idea I could propose.
Well, here is another, completely different one.
Instead of rearranging the translation process to let \fine abort translation,
let translation run normally until the e
On Thu, 2022-07-07 at 18:48 +0200, Jean-Charles Malahieude wrote:
> Le 06/07/2022 à 20:51, Jonas Hahnfeld a écrit :
> >
> > ... which, as far as I understand, is processed by some form of a bot,
> > right? At least that one message was taken care of *very* quickly...
> >
>
> I have to confess th
Le 06/07/2022 à 20:51, Jonas Hahnfeld a écrit :
... which, as far as I understand, is processed by some form of a bot,
right? At least that one message was taken care of *very* quickly...
I have to confess that _I am_ the bot… until the mail announcing new
releases are directly sent to the F
On 7/6/22 20:51, Jonas Hahnfeld wrote:
... and I think this is sufficient, at least it was precisely the
reason we sent in 2.21.7 because that a) had many translation changes
due to fixing an "infrastructure" bug and b) was the last version
before branching. I intended do follo
vz translationproject.org:: tp/latest/lilypond/ po
>
> and commit them before making any release? Note that the lilypond.pot
> will always be one step beyond the language files.
>
> Many software acknowledge the FTP only when making a stable RC and not
> at every development release
Le 06/07/2022 à 13:31, Jean Abou Samra a écrit :
On 7/6/22 11:15, Werner LEMBERG wrote:
The PO template that is the basis for PO files needs to be updated
at every release by notifying the coordinator of the release.
That's a maintenance cost. Right now, we're not paying it, and the
result is t
since that date:
- Chinese
- Hungarian
- Italian
- Spanish
- French
- Japanese
- Catalan
The latter shows which languages saw updates of po files:
- Esperanto
- French
- Japanese
- Dutch
- Catalan
- Swedish
As you can see, the lists are about similar in length. Documentation
actually wins, and
> The PO template that is the basis for PO files needs to be updated
> at every release by notifying the coordinator of the release.
> That's a maintenance cost. Right now, we're not paying it, and the
> result is that the PO template any translators would base their work
> on is from LilyPond 2.
On 7/6/22 01:14, Jean Abou Samra wrote:
It's awkward to have po files in the TP but not the documentation, as
that just doubles the amount of contributing processes that a new
translator has to learn.
Sorry, I meant: it's awkward to have po files translated via the TP but
not documentation
Hi,
Yesterday, I found myself wanting to correct a trivial markup error in
the output of `lilypond --help`. To do that fix, I first have to
register as a member of the translation team for French on the
Translation Project, by contacting the team coordinator, and learn how
to use the
On 7/5/22 18:39, Dan Eble wrote:
I'll try to explain this more clearly. I doubt that we actually disagree about
this. I did not mean that those two cases should be handled the same in every
respect. My thoughts were focused on creating spanners at the end of the score.
Warning about a score
> On Jul 5, 2022, at 08:05, Dan Eble wrote:
>
> On Jul 5, 2022, at 02:11, Jean Abou Samra wrote:
>>
>> On 7/5/22 02:03, Dan Eble wrote:
>>> Don't focus too closely on \fine. Engraving in the final timestep should
>>> be orderly whether it is caused by \fine or the natural end of the input.
On Jul 5, 2022, at 02:11, Jean Abou Samra wrote:
>
> On 7/5/22 02:03, Dan Eble wrote:
>> Don't focus too closely on \fine. Engraving in the final timestep should be
>> orderly whether it is caused by \fine or the natural end of the input.
>> You're just more likely to get into interesting sit
On 7/5/22 02:03, Dan Eble wrote:
Do you envision having the framework record events as they are dispatched to
pre-listeners and then replay them to dispatch them to post-listeners?
Yes.
Would you expect events to be dispatched to post-listeners in the same global
order as the pre-listeners?
On Jul 4, 2022, at 17:12, Jean Abou Samra wrote:
>
> | | pre-listeners <- RENAMING
> | |
> | pre-process-music => | pre-process-music
> | |
> |
Moving some of the discussion from
https://gitlab.com/lilypond/lilypond/-/merge_requests/1451
to the mailing list.
In case that helps, this is a diagram of a revised translation
cycle that I was musing about for some (very) distant future:
Before After
Le 02/04/2022 à 16:10, Robert Ernest a écrit :
Hello,
how can I help with translation, seeing as the webpage is mistranslated?
Best Regards,
Robert Ernest
Hi Robert,
What is your native language? In case it's French (as I
would guess from your name), the current translator is
Jean-Ch
On Apr 2, 2022, at 10:10, Robert Ernest wrote:
>
> how can I help with translation, seeing as the webpage is mistranslated?
>
Welcome, Robert.
See the Contributor's Guide, which is available in HTML or PDF at
https://lilypond.org/development.html.
Regards,
—
Dan
Hello,
how can I help with translation, seeing as the webpage is mistranslated?
Best Regards,
Robert Ernest
than
English content.
Jonas
Am Freitag, dem 18.12.2020 um 22:32 +0100 schrieb Federico Bruni:
Ok, thank you Jonas!
There's a third option I like more:
3) mandatory translation of search-box.ihtml (it's already in the
list
of files to be translated in the CG manual)
I may contact
and
the website early next year, IMHI heavily outdated pages are worse than
English content.
Jonas
Am Freitag, dem 18.12.2020 um 22:32 +0100 schrieb Federico Bruni:
> Ok, thank you Jonas!
>
> There's a third option I like more:
>
> 3) mandatory translation of search-box.ih
Ok, thank you Jonas!
There's a third option I like more:
3) mandatory translation of search-box.ihtml (it's already in the list
of files to be translated in the CG manual)
I may contact the cs translator to get it translated and/or ask for
help on lilypond-user.
Il giorno ven, d
There's no Documentation/cs/search-box.ihtml, so IIRC lilypond-
texi2html.init searches for the fallback in Documentation/. Now we
could of course adapt this check, but this feels odd from a language
perspective. Two more ideas:
1) Adapt the check-translation script
2) Also add a symlink
ce is welcomed! :-)
>
>
>
> Il giorno mer, dic 9 2020 at 00:38:05 +0100, Federico Bruni
> ha scritto:
> > Any reason why search-box.ihtml is in Documentation/ instead of
> > Documentation/en?
> > It seems it's causing troubles to the check-translation script:
On Dec 18, 2020, at 15:26, Federico Bruni wrote:
>
> I've just submitted a MR:
> https://gitlab.com/lilypond/lilypond/-/merge_requests/545
>
> but it doesn't pass the doc build pipeline.
>
> It worked for me on my computer, even though only english docs were built.
> Basically I just added 'en'
other languages are appended.
Any advice is welcomed! :-)
Il giorno mer, dic 9 2020 at 00:38:05 +0100, Federico Bruni
ha scritto:
Any reason why search-box.ihtml is in Documentation/ instead of
Documentation/en?
It seems it's causing troubles to the check-translation script:
$ cd Docume
Any reason why search-box.ihtml is in Documentation/ instead of
Documentation/en?
It seems it's causing troubles to the check-translation script:
$ cd Documentation
$ make ISOLANG=fr check-translation | grep 'diff --git'
warning: fr/search-box.ihtml: 128 fatal: path
'Doc
7;s not my understanding.
>
> Rather, what one translator suggested, namely:
>
>- forking the repo
>
>- Creating another working branch
>
>- Issuing a MR from this branch, against translation branch
>
>- waiting for a) the MR to be merged, then b)
ng another working branch
- Issuing a MR from this branch, against translation branch
- waiting for a) the MR to be merged, then b) translation branch to
be merged onto master
is not exactly 'ideal'. Translation branch is a safe net, now MR are a
safe net. I thougth (wrongly)
Am Sonntag, den 21.06.2020, 14:50 +0200 schrieb Jean-Charles
Malahieude:
> Le 21/06/2020 à 13:53, Jonas Hahnfeld a écrit :
> > Am Sonntag, den 21.06.2020, 13:20 +0200 schrieb Han-Wen Nienhuys:
> > > BTW, regarding translations:
> > >
> > > I notice
Le 21/06/2020 à 13:53, Jonas Hahnfeld a écrit :
Am Sonntag, den 21.06.2020, 13:20 +0200 schrieb Han-Wen Nienhuys:
BTW, regarding translations:
I notice that translation work gets merged as
"commit cb1b3c1fb0c1d9dc1fb6fdadb0907c07b8a692e5
Merge: 22eca98efe b47e5def69
Author: Jean-Ch
Am Sonntag, den 21.06.2020, 13:20 +0200 schrieb Han-Wen Nienhuys:
> BTW, regarding translations:
>
> I notice that translation work gets merged as
>
> "commit cb1b3c1fb0c1d9dc1fb6fdadb0907c07b8a692e5
> Merge: 22eca98efe b47e5def69
> Author: Jean-Charles Malahieude
>
El 21/6/20 a las 13:20, Han-Wen Nienhuys escribió:
BTW, regarding translations:
I notice that translation work gets merged as
"commit cb1b3c1fb0c1d9dc1fb6fdadb0907c07b8a692e5
Merge: 22eca98efe b47e5def69
Author: Jean-Charles Malahieude
Date: Sat Jun 20 17:44:05 2020 +0200
Merge b
El 21/6/20 a las 12:50, Jonas Hahnfeld escribió:
Granted to @pacovila. You also had access to Savannah before the
transition, and I don't see a reason to deny the equivalent level of
access.
If you want, you can now press 'Merge' button for the MR above or just
push the commit
BTW, regarding translations:
I notice that translation work gets merged as
"commit cb1b3c1fb0c1d9dc1fb6fdadb0907c07b8a692e5
Merge: 22eca98efe b47e5def69
Author: Jean-Charles Malahieude
Date: Sat Jun 20 17:44:05 2020 +0200
Merge branch 'master' into translation"
cou
ld just
> push to translation branch directly on the official repo.
I mean it's not wrong, but I don't think we should make this more
complicated than needs to be. Code reviews make sense for development
work, but the translations have done well without (at least from my
perspective)
Hello,
https://gitlab.com/lilypond/lilypond/-/merge_requests/183
I am told that the whole approach of forking and doing a MR et cetera is
not the best way to contribute to translations, and that I should just
push to translation branch directly on the official repo.
May I get that access
Am Mittwoch, den 08.04.2020, 09:41 +0200 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > Hi David,
> >
> > I think these have gone via translation to master, so safe to delete?
>
> I think so.
$ git push origin :dev/
Jonas Hahnfeld writes:
> Hi David,
>
> I think these have gone via translation to master, so safe to delete?
I think so.
--
David Kastrup
Hi David,
I think these have gone via translation to master, so safe to delete?
Jonas
signature.asc
Description: This is a digitally signed message part
feld <
>> > > hah...@hahnjo.de
>> > >
>> > > > writes:
>> > > > Perfect. I only restored the following files from the branch to keep
>> > > > the Portuguese translation:
>> > > > * Documentation/web/server/lilypond.o
> > > > writes:
> > > > Perfect. I only restored the following files from the branch to keep
> > > > the Portuguese translation:
> > > > * Documentation/web/server/lilypond.org.htaccess
> > > > * ROADMAP
> > > > * python/l
Jonas Hahnfeld writes:
> Am Dienstag, den 03.03.2020, 17:50 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>> > Perfect. I only restored the following files from the branch to keep
>> > the Portuguese
Am Dienstag, den 03.03.2020, 17:50 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> > Perfect. I only restored the following files from the branch to keep
> > the Portuguese translation:
> > * Documentation/web/server/lil
launch a 2.21 fairly soon afterwards, and the problem you're
> citing would then go away.
The 2.21 release depends on merging the translation work back in. I
probably should start with that already: we don't have many outstanding
contributions there I guess.
Too bad I never understo
But it doesn't make sense to point VERSION_DEVEL to documentation that
is actually older than that of 2.20, does it?
I do not really know what is correct here with respect to our
semi-automatic webpage update mechanism. I just remember that we had
problems last time round.
--
David Kastrup
"Phil Holmes" writes:
> - Original Message - From: "David Kastrup"
> To: "Federico Bruni"
> Cc: ; ; "Phil
> Holmes"
> Sent: Saturday, February 22, 2020 10:54 PM
> Subject: Re: 2.20.0 release coordination with translation. Ot
- Original Message -
From: "David Kastrup"
To: "Federico Bruni"
Cc: ; ; "Phil Holmes"
Sent: Saturday, February 22, 2020 10:54 PM
Subject: Re: 2.20.0 release coordination with translation. Other
showstoppers?
Federico Bruni writes:
Il giorno sab
El 22/2/20 a las 19:25, David Kastrup escribió:
So there is a bit of leeway for improvements in the 2.20 documentation
even after the 2.20.0 line.
Good. I am late, sorry. But I'll hopefully sync Doc-es in a few days.
--
Francisco Vila, Ph.D. - Badajoz (Spain)
paconet.org , lilypond.es
hits the fan.
Ok, then I pushed to translation branch my work so far.
I guess I'll push the final update on Monday.
Federico Bruni writes:
> Il giorno sab 22 feb 2020 alle 19:25, David Kastrup ha
> scritto:
>> German Changes file has been added by now. Where are we with regard
>> to
>> the other translations? Federico?
>
> I'm still working on it.
> My spare time is limited and the changes by Werner require
Il giorno sab 22 feb 2020 alle 19:25, David Kastrup ha
scritto:
German Changes file has been added by now. Where are we with regard
to
the other translations? Federico?
I'm still working on it.
My spare time is limited and the changes by Werner requires a lot of
meticulous edits.
If you
David Kastrup writes:
> Federico Bruni writes:
>
>> Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni
>> ha scritto:
>
>>> I'm working on the italian update and I hope to be ready before
>>> Thursday night.
>>>
>>
>> Can
Il giorno gio 20 feb 2020 alle 15:21, David Kastrup ha
scritto:
I could not actually get any script to do anything helpful. I
remember
this being different at some point of time in the past.
I use `make check-translation` regularly and has always worked.
But you should be aware that:
1
dinate in order to avoid duplicate
>> effort?
>> I got kind of a headache so far. Hats off to people who tackle a
>> whole
>> translation rather than just a puny file.
>
> Indeed, it requires a strong commitment... it took me almost 10 years
> to translate all th
headache so far. Hats off to people who tackle a
whole
translation rather than just a puny file.
Indeed, it requires a strong commitment... it took me almost 10 years
to translate all the manuals!
Translation infrastructure is another area which could be improved.
After 2.20 is out I'l
Federico Bruni writes:
> Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni
> ha scritto:
>> I'm working on the italian update and I hope to be ready before
>> Thursday night.
>>
>
> Can we have one day delay? So deadline to push to translation branch
&
Hi all,
at university, we actually *did* use the term "Fluchtsymbol" as
translation for "escape character". Using the English term "escape" in
German language is just a (common but unnecessary) anglicism.
(But in a text book for one of the courses at
Il giorno gio 13 feb 2020 alle 11:11, Lukas-Fabian Moser
ha scritto:
What's the right place to send such suggestions to? If there's going
to be a new stable release soon, maybe it would be nice to get some
of the more amusing translation gaffes fixed in time.
LilyPond has a dedicat
cedure."
msgstr "point-and-click-Argument zu Ablauf verändert"
("Ablauf" being a literal translation of 'procedure' that is wrong in a
software context) and the famous
#: lexer.ll:947
#, c-format
msgid "unknown escaped string: `\\%s'"
msgstr "
translated. If all
mods are known before translation a SequentialMusic expression for each
Context might be created and then added to the music.
... this is not thought to the end.
Jan-Peter
Am 23.08.2017 um 19:09 schrieb David Kastrup:
Jan-Peter Voigt writes:
Hi David,
thank you for your work
Jan-Peter Voigt writes:
> Hi David,
>
> thank you for your work on this! I will try/investigate it later this
> evening or tomorrow in the morning.
It's half-baked half-finished work. I vaguely remember that I could not
figure out exactly how to make it do 100% of what I wanted it to do when
it
Hi David,
thank you for your work on this! I will try/investigate it later this evening
or tomorrow in the morning.
Best
Jan-Peter
Am 23. August 2017 18:33:15 MESZ schrieb David Kastrup :
>David Kastrup writes:
>
>> David Kastrup writes:
>>
>>> Jan-Peter Voigt writes:
>>>
Do you have an
David Kastrup writes:
> David Kastrup writes:
>
>> Jan-Peter Voigt writes:
>>
>>> Do you have another idea how to do that?
>>
>> Timing is established by iterators and they work on music expressions,
>> not events. So you need to have an iterator in the race from the start.
>> Few iterators ha
David Kastrup writes:
> David Kastrup writes:
>
>> Jan-Peter Voigt writes:
>>
>>> Do you have another idea how to do that?
>>
>> Timing is established by iterators and they work on music expressions,
>> not events. So you need to have an iterator in the race from the start.
>> Few iterators ha
Hi David (et al.),
> Iterators are not user-definable at the moment. Either a general
> facility or a more specific "wait-iterator" would seem warranted.
[…]
> it might make more sense to work on actual infrastructure for this
> rather than fudging around with existing facilities not intended for
David Kastrup writes:
> Jan-Peter Voigt writes:
>
>> Do you have another idea how to do that?
>
> Timing is established by iterators and they work on music expressions,
> not events. So you need to have an iterator in the race from the start.
> Few iterators have variable length. The sequentia
ent/measurePosition. These mods are applied
> in one of the engravers slots, that is either (most times) in the
> start-translation-timestep, acknowledger, listener or the
> process-music function.
> Now, if there is no stop/break in translation the function will not
> get called:
&
f the
engravers slots, that is either (most times) in the
start-translation-timestep, acknowledger, listener or the process-music
function.
Now, if there is no stop/break in translation the function will not get
called:
\editionMod target 1 1/8 Voice \override ...
will not get called if the mus
Le 08/08/2017 à 16:48, Masamichi Hosoda a écrit :
2.19.65 has been released,
it seems that it does not contain some recent translations.
[...]
Which branch should the translators translate?
e.g. translate the English document in the master branch,
commit to the translation branch, etc
Hosoda-san,
You may also want to include the translation email alias.
James
On Tue, 08 Aug 2017 23:48:50 +0900 (JST)
Masamichi Hosoda wrote:
> 2.19.65 has been released,
> it seems that it does not contain some recent translations.
>
> e.g.
> eb38c33a95 Doc-ja: fix cindex in
.
9f53d74eaf Web: Add a new document to what We Wrote list.
ce1c9d0ea4 Doc-ca: Catalan translation of the notation manual: expressive.itely
and text.itely
etc.
Is the translation branch not contained in the release?
Or will it be contained in the next release?
On the other hand,
the current "transl
Il giorno gio 19 gen 2017 alle 8:56, Walter Garcia-Fontes
ha scritto:
I'm trying "make" in the translation branch to test some new
translations of mine, and I'm getting the below error. I'm doing it in
a version of lilydev I downloaded some months ago, should I rei
I'm trying "make" in the translation branch to test some new
translations of mine, and I'm getting the below error. I'm doing it in
a version of lilydev I downloaded some months ago, should I reinstall
the new version of lilydev? Curious thing is it was compiling fine
Werner LEMBERG writes:
> In lines 84 and 86 of translation-functions, character U+2009 gets
> used in the single-character string. Is this intentional? Lines 94
> and 96 use ordinary spaces...
>
> In case U+2009 is really wanted, this (a) deserves a comment and (b)
> lines 9
1 - 100 of 746 matches
Mail list logo
