Lyric line metadata should allow for multiple languages in a single lyric line context

[rossme]

I'd like to propose that an individual lyric line metadata should be able to handle multiple languages. The reason I brought this up was because I was taking a look at this recently merged PR.

It can be quite common, particularly in classical music for a lyric line to contain multiple languages. Latin and English, Hebrew and German for example within the same lyric line context.

Great work on this by the way 🚀

[adrianholovaty]

Thanks for the suggestion! It makes sense that a single lyric line could possibly contain multiple languages, but I've got a few questions:

• How would you propose that situation be encoded? A language encoding on a per-syllable basis? Or would a value like "multiple" for the lyric line suffice?
• If you're proposing that language be encoded on a per-syllable basis, what is the specific use case for encoding that information so granularly?

[rossme]

Inheritance

I was recently looking at how HTML handles language inheritance.

In HTML, lang values cascade from parent to child unless overridden. Just as in HTML, where lang can be declared at the document or element level and overridden at a finer-grained level, one idea might be for MNX to support a default lang on the lyric line, with the option to override at the syllable level if needed.

The simpler choice

I don’t necessarily prefer the granular (syllable) level, and I don’t think a "multiple" flag is needed. Instead, lang could simply accept an Array when multiple languages are present, e.g.:

"global": {
  "lyrics": {
    "lineMetadata": {
      "label": "verse1",
      "lang": ["la", "en"]
    } 
  }
}

In this case, the software consuming the JSON determines the number of languages from the Array length — similar to how the number of measures in MNX is determined by counting the number of Hash objects in the measures Array.

I also noticed in the example that it says "label": "Spanish", but I presume using an Array for "lang" would not affect "label", as we infer the actual language from the ISO code, while the label can remain as a descriptive String.

Real world example

In terms of a real-world use-case, there are a number of works by polyphonic composers that contain both languages on a single lyric line, as alternate text added by the editor, I think mixed languages on a single lyric line is standard practice particularly in choral and sacred music (and plenty of other genres!). I think it would be an important addition for searching/filtering by multiple languages, and for analytic tools used by musicologists.

To syllable, or not to syllable

It would add more complexity at the syllable level, but I'm open to the idea if others feel it is a better approach and necessary.

[samuelbradshaw]

In the future, these kind of language annotations may be helpful for AI systems that can generate sung audio from the sheet music. In the shorter term, they might be useful for accessibility (text to speech for someone navigating the sheet music).

[dougheyer]

Very interesting topic! I just did a test with ChatGPT to see how he/she/it handled mixing words from multiple languages in a single phrase. ChatGPT did well. For example, I gave him the sentence: "I want to know si tu puedes hablar 中国话, si me contestas en 日本话 I will go to 东京". And he understood it perfectly: “I want to know if you can speak Chinese; if you answer me in Japanese, I will go to Tokyo.”

Then I tried phrases with syllables separated by hyphens. He had no problem putting the syllables together to form words. Of course there will be cases where the language will be ambiguous: many words in Spanish, French and Italian are spelled the same; Mandarin and Cantonese mostly use the same characters, but pronounce them differently.

So I gave him this query: let's say "en:" is for English, "fr:" for French, "sp" for Spanish; then if I gave you a phrase like "sp:sensible fr:sensible en:sensible" would you know which language's pronunciation to use with each word?" His response was: "Excellent test — and yes, absolutely. If you prefix each word with a language code like that (e.g., en:, fr:, es: or sp:), I can correctly interpret which language each word is intended to be in — and then apply the correct pronunciation, stress pattern, and meaning for that language, even if the spelling happens to coincide (as in your example)."

It looks like AI will be able to handle multiple language situations. I have just done some more testing, and ChatGPT knows what "xml:lang" and "lang" (HTML) means when encountered in a document. So maybe you need (1) a way to specify the default lyric language, (2) a way to specify a different language for individual words, maybe by prefixing a standard (invisible) language code + ":" to the word (e.g. "en:hello"), and (3) make sure to use one of the super fonts that can handle multiple languages.

P.S. I can't see the need for a language specification at the syllable level, unless you're doing stand-up comedy.

Hope this little adventure with AI will help the discussion!

[rossme]

@adrianholovaty any further thoughts on this?

[dougheyer]

Yes. I have thought more about this, and from a schema design standpoint prefixing a language code may not be the best solution.

(1) What is text? There is a general issue which maybe has not been thoroughly addressed: what, where and how do you want to allow markups and Regex patterns in MNX text? The MusicXML schema already uses "&xml:lang" (does this imply that all XML markup is OK?), and some of the type definitions use Regex patterns or indicate the optional use of CSS elements in text. This not only adds complexity for the developer, but also has implications for what an end user can expect to use when adding/modifying text fields. It looks like text should be a special schema subject in itself: text is much more than just a String.

(2) The human voice as instrument: I think the human voice should be treated just like any other instrument, with syllables (and the language spoken/sung) being just additional acoustic phenomena of the associated "chord" event. Bear in mind that lyrics are frequently meant to be spoken (or shouted or whispered), rather than sung; clicking of fingers, clapping of hands, stomping on the floor...what a wonderful, hybrid instrument! But aren't these things just an extension of accents and embellishments (mordents, turns, etc.) and all the weird ways other instruments can alter their sounds?

(3) So there are these two "simple" issues: text, and the human instrument. Good luck!

As a P.S. Yes, also RTF. See dspreadbury issue #280

[williamclocksin]

My Calliope system (currently being rewritten from Objective-C into Scala and Java) tagged each syllable with a two-byte language code (ISO 639-1). This may seem overkill because words tend not to change language within themselves, but it was convenient because syllables are first class objects each with their own font, hyphenation, relative placement, and other details. So, may as well add a language code. And, I only produced scores in English, Latin, Italian, and Quechua. Also, I couldn’t find a really good use case for language tags, but others might. On 10 Oct 2025, at 15:16, Ross Buddie ***@***.***> wrote:rossme left a comment (w3c/mnx#444) @adrianholovaty any further thoughts on this? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>