Re: x-scheme fails to parse multiline strings

[Tim Janik]

On Fri, 21 Apr 2006, Bruno Haible wrote:

> Tim Janik wrote:
> > here's another one:
> >
> > (bse-script-register 'part-harmonic-transposer
> >                       ""
> >                       (N_ "/Part/Harmonic Transposer")
> >                       ;; FIXME: the description may be suboptimal; the problem 
> > is
> >                       ;; that I can't precisely describe details of musical 
> > theory
> >                       ;; in english. -- stw
> >                       (N_ "The harmonic transposer takes the selection of a part 
> > "
> >                           "and transposes it to different harmonies. If you for 
> > "
> >                           "instance have selected a measure filled with C major 
> > "
> >                           "chords, and enter \"C,Am,F,G\" as harmonic sequence, 
> > "
> >                           "the result will be four measures, filled with C major, 
> > "
> >                           "A minor, F major and G major chords. "
> >                           "\n\n"
> >                           "This also works for melodies, so you can transpose a 
> > "
> >                           "whole melody written in G major to D minor. The standard 
> > "
> >                           "scales used in church music (ionian, dorian, phrygian, 
> > "
> >                           "lydian, mixolydian, aeolian, locrian) are also supported: 
> > "
> >                           "it is for instance possible to write Ddorian or Caeolian. 
> > "
> >                           "The aeolian scale is equivalent to minor and the ionian 
> > "
> >                           "scale is equivalent to major. "
> >                           "\n\n"
> >                           "Since musically, there is no preference on whether to 
> > transpose up or "
> >                           "down it is possible to specify the first harmony that 
> > will be transposed "
> >                           "down (all harmonies below this will be transposed up). It 
> > is possible "
> >                           "to omit this value. Then all notes will be transposed 
> > up.")
> >                       "Stefan Westerfeld"
> >                       "GNU General Public License"
> >                       (bse-param-part   (N_ "Part"))
> >                       (bse-param-string (N_ "Harmony Sequence") "C,Amin,F,G")
> >                       (bse-param-string (N_ "Transpose down starting at") "F"))
>
> Two remarks on this one:
>
> - It is welcome to split the strings at paragraph boundaries, i.e. let the
>  translator translate three paragraphs rather than one large block. The
>  reason is that when small changes occur to the English strings, it helps
>  the translator to see which paragraph has changed. This is harder to see
>  when the entire string has 18 lines.

ok.

> - The absence of newlines in these strings indicates that some formatting
>  occurs to them during the rendering/display process. This is a good thing,
>  because it usually means that there is word-wrapping that adapts to the
>  available width. You can change this rendering so that newlines are
>  treated in same way as spaces, like in HTML, and then you can write it
>  with real multi-line strings:
>
> (bse-script-register 'part-harmonic-transposer
>                      ""
>                      (N_ "/Part/Harmonic Transposer")
>                      ;; FIXME: the description may be suboptimal; the problem is
>                      ;; that I can't precisely describe details of musical 
> theory
>                      ;; in english. -- stw
>                      (list
>                        (N_ "
> The harmonic transposer takes the selection of a part
> and transposes it to different harmonies. If you for
> instance have selected a measure filled with C major
> chords, and enter \"C,Am,F,G\" as harmonic sequence,
> the result will be four measures, filled with C major,
> A minor, F major and G major chords.
> ")
>                        (N_ "
> This also works for melodies, so you can transpose a
> whole melody written in G major to D minor. The standard
> scales used in church music (ionian, dorian, phrygian,
> lydian, mixolydian, aeolian, locrian) are also supported:
> it is for instance possible to write Ddorian or Caeolian.
> The aeolian scale is equivalent to minor and the ionian
> scale is equivalent to major.
> ")
>                        (N_ "
> Since musically, there is no preference on whether to transpose up or
> down it is possible to specify the first harmony that will be transposed
> down (all harmonies below this will be transposed up). It is possible
> to omit this value. Then all notes will be transposed up.
> "))

eek, this'd be a major API change, unless instead of 'list', we'd
use 'string-append'. but then your paragraph idea isn't really reflected...

other than that, it also breaks the indentation structure the code 
previously had. i really wouldn't want to do that, especially since
we don't (have to) do that in C either.

>                      "Stefan Westerfeld"
>                      "GNU General Public License"
>                      (bse-param-part   (N_ "Part"))
>                      (bse-param-string (N_ "Harmony Sequence") "C,Amin,F,G")
>                      (bse-param-string (N_ "Transpose down starting at") "F"))
>
> Another option is to move such long explanations to HTML files and use the
> extraction/merge scripts for HTML that KDE uses (similar to xgettext in
> spirit, just for HTML).

in this particular case, i'm not very fond of moving the strings out of
the code. having the descriptions inlined is a good way to ensure they
stay updated and people are bothered enough to actually create them in the
first place. (also, by moving them into a seperate file, scripts couldn't
be self contained anymore which would be another inconvenient structural
change)

> > don't you agree that supporting multi arg strings (as we do in C as well)
> > is the better option here?
>
> Not necessarily: With the automatic string concatenation,
>  - You (the programmer) have to put double-quotes on each line,
>  - The translator wouldn't know whether he should insert newlines or not.

that is no different from the C translations though. and to decide on the
newlines, i'll look/ponder some more the paragraph suggestion you made.
thanks for that.

still, support for multi-string parsing really is what beast needs from
xgettext. so is it conceivable that this kind of support could be added
to xgettext (in which case i'll dig x-scheme.c next) or is that something
you deliberately refuse to support (in which case i'll have to look into
parsing alternatives)?

> Bruno

---
ciaoTJ