Translation troubles: variables

MusicBrainz Development
, ,
1

Translating variables in strings for relationships always confuses me, but now I am really stumped. How am I supposed to untangle/interpret this string: “is/was {additional:an|a} {additional} {original} member of”?

Any help is welcome. :slight_smile:

1 Like
2

This string has two parameters additional and original, hence four outputs are possible:

  • (neither additional nor original): “is/was a member of”
  • additional (and not original): “is/was an additional member of”
  • (not additional but) original: “is/was a original member of”
  • both additional and original: “is/was an additional original member of”

This confused me as well :sweat_smile:

Edit 1: Note that the third phrase is not correct, it should be “an original”. This is a known limitation of the current phrasing system, see MBS-9070.

Edit 2: I moved your topic to the most appropriate category and added some tags

4 Likes
3

For a more general explanation, {additional:an|a} means: If the “additional” attribute is set, output “an”; otherwise, output “a”. There are two short forms available, too:

  • {additional:foo} means the same as {additional:foo|}, i.e. if the attribute is set, output “foo”, otherwise nothing.
  • {additional} is equivalent to {additional:additional|}, i.e. if the attribute is set, output its name, otherwise nothing. This is mostly useful for English, less so for other languages, where it usually needs to be replaced by {additional:whatever}.
3 Likes
4

Thank you both. I keep tripping over this kind of strings. :slight_smile:

I think MBS-9070 could be solved by having separate strings on Transifex for every possible combination of link phrases. That would also make some hard if not impossible to translate link phrases translatable. But I understand that is a lot of work and volunteers will be hard to find.

1 Like
5

Do you really want to translate “{live} {medley:medley including a} {partial} {instrumental} {cover} recording of” 32 times, though? (Or even 96 times, because the reverse and long link phrases also would decompose into 32 versions each.)

2 Likes
6

I think I would prefer that, yes. :wink:

That’s a ten-word string, but on average you’d probably have to write five words for every phrase. With 96 variations and a leisurely pace of 30 words per minute, that would take me 16 minutes. Just imagine how long it takes me to come up with a translation of “{live} {medley:medley including a} {partial} {instrumental} {cover} recording of” that would formulate a correct sentence for every possible combination in Dutch (if that’s even possible). And it’s probably a lot easier for me because I translate into a language closely related to English. I can’t imagine how a Polish or Japanese translator might manage that (of course, it could happen to be a lot easier for them, I wouldn’t know).

1 Like
7

Do we have a choice? Not every language is as simple as English, and even with English the current syntax cannot cover every case correctly (c.f. „a original member“).

Sure, we could invent a more powerful DSL, or even allow limited Perl or LUA or whatever expressions, to cover all bases… but programming may not be the forté of the one volunteer we get to translate the UI to Navajo.

2 Likes
8

I agree that strings are too complex and that they should not be increased one-hundredfold.

Actually, I am very dubious about the feasibility of generating correct sentences. It seems to be difficult to achieve in English already and that would require even more sophisticated syntax.

For example, see the long link phrase at Relationship Types / Artist-Recording / Instrument:

performed {additional} {guest} {solo} {instrument:%|instruments} on

This is currently impossible to translate correctly in many languages that put a specific article in front of instrument name. Examples in French : de la harpe, du hautbois, de l’harmonica. That would require to add translatable strings for all usages (play, arrangement) of 700+ instruments.

What is our goal: almost correct English sentences or translatable strings in telegraphic style?

9

Strings would become a lot less complex if they didn’t have to accommodate every combination of attributes. But that would require lots of different link phrases.[quote]
Actually, I am very dubious about the feasibility of generating correct sentences. It seems to be difficult to achieve in English already and that would require even more sophisticated syntax.
[/quote]
I agree that more complex sentences wouldn’t help. But that’s exactly what I don’t want. I would like more different link phrases, so that each one can become less complex.[quote]
This is currently impossible to translate correctly in many languages that put a specific article in front of instrument name.[/quote]
True, and that is true for all variables in a translatable string. In most languages there are ways around that though, even if that solution is an ugly “a(n)”. This shouldn’t stop us from trying to solve any other problems with translating strings with multiple variables though.

English sentences that are as correct as possible and can be translated into grammatically correct sentences in the target language. These aren’t mutually exclusive. I’m not sure where that idea about a telegraphic style comes from?

10

I have specifically pointed at list variables. Ugly “du/de l’/de la/des” is one reason that I am dubious about sentences. It is more difficult to read such text rather than simple enumeration.

These aren’t mutually exclusive provided that another implementation could make it possible to combine both. Multiplying strings to make them simpler would be a good start but not an end.

Sorry. By strings in telegraphic style, I just meant enumerations, by opposition to sentences.

11

There are currently 145 (among 1130) relationship messages with attribute variables:

  • 93 relationship messages with 1 attribute variable
  • 18 relationship messages with 2 attribute variables
  • 2 relationship messages with 3 attribute variables
  • 23 relationship messages with 4 attribute variables
  • 9 relationship messages with 5 attribute variables

It would require 930 messages (that is 785 additional messages) to get rid of attribute variables. Would that be an improvement? Would that be less error prone?

I started to document variables for translators at https://wiki.musicbrainz.org/Server_Internationalisation#Variables (@chirlu: can you review it?)

1 Like
12

I guess a better example for % would be attributes that can have many values, such as instruments: played {instrument:%|something} on may become “played piano on” or “played something on”.

Looks good otherwise.

13

I maintain that it would be an improvement. Of course more strings give more opportunity for error, but each string would be less complex (because it has to create a correct sentence for only one mutation, instead of a dozen correct mutations for some strings in the current situation). And generally less complexity means fewer errors. There’s also the problem that a lot of the more complex strings simply can not be translated correctly in many languages, translator errors aside.

I estimate that it would take at most 3 hours to translate those extra strings. That sounds like a lot, but compared to the amount of hours I’ve already spent translating MusicBrainz, it’s peanuts.

But I seem to be the only one with this opinion, so I’ll let it rest. Your translation variables documentation is really appreciated! Before that I had to look things like that up in ancient mailing list messages and I was still never sure about the outcome.

14

@chirlu: Thanks, I added your example.
@mfmeulenbelt: You’re welcome, I linked this topic to MBS-5781 (open unlike MBS-9070).