attributes in the relationship type dropdown not translated?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

attributes in the relationship type dropdown not translated?

Maurits Meulenbelt-2
Hello,

The attributes in the dropdown list on the add relationship page don't
seem to get translated. Instead of {original:translated} displaying as
{translated}, it's still {original:translated}.
At first I thought it was an issue with my translation, but the same
thing occurs in the French and German translations, so it looks like I'm
in the clear. ;)
A URL with an example is below.

http://musicbrainz.org/edit/relationship/create?type0=release&type1=artist&entity0=79cc3b94-3541-42e7-b92c-1ca910aa0b43&entity1=11ae9fbb-f3d7-4a47-936f-4c0a04d3b3b5&returnto=http%3A%2F%2Fbeta.musicbrainz.org%2Frelease%2F79cc3b94-3541-42e7-b92c-1ca910aa0b43%2Frelationships

Maurits Meulenbelt

P.S. Not related to this issue, but to translation in general: I've sent
a mail to the style mailing list concerning making instrument entities,
and I'm especially interested in a translators point of view.

_______________________________________________
MusicBrainz-i18n mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n
Reply | Threaded
Open this post in threaded view
|

Re: attributes in the relationship type dropdown not translated?

Alexander Dupuy-3
Maurits wrote:
The attributes in the dropdown list on the add relationship page don't 
seem to get translated. Instead of {original:translated} displaying as 
{translated}, it's still {original:translated}.

You seem to have a slight misunderstanding about the (fairly technical) mechanism of relationship types and their descriptive strings.

A relationship string like '{additional:additionally} {guest} {solo} performed' means the following:

* this is a performance relationship
* there are three optional attributes to the relationship
  * 'additional' (which is written in the text string as 'additionally')
  * 'guest' (which is written the same in the text string)
  * 'solo' (which is written the same in the text string)

It's not that {additional:additionally} is in an {original:translated} form (although for reasons noted below, you will see something like that in most translations, so it is not surprising that you interpreted it this way).

There are in a way four different strings that need to be translated - the three separate attributes and the entire text string for the relationship (that will be used when displaying a relationship that exists in - or is being added to / removed from - the database):

* additional
* guest
* solo
* {additionally} {guest} {solo} performed

The last (fourth) string is really the one that should be displayed to the user in the dropdown menu - rather than the full relationship string.  The relationship strings need to have the {attribute:text} form for functional reasons (so that the UI can decide whether to include the text or not) but there is really no reason to include the attribute string in the dropdown when an alternate text is provided.  Stripping out the unneeded attribute names can easily be done by a simple regex replacement (after localization, of course) like this: s/\{\w+:/{/ (mixing sed s/// syntax with Perl/PCRE regexp syntax).

I think that the above would be a simple and helpful improvement to the internationalization/localization of the UI.  There are some other problems with relationship strings that I will also mention here, but some may wish to stop reading at this point, since the problems are hard, complicated, and unlikely to be addressed very soon.

The fourth string in a way is actually eight different variants with all the possibilities of additionally, guest, and solo being present or absent.  (Semantically, for this relationship, combining both 'additionally' and 'solo' seems a bit odd, so we might not care so much about the two variants that have both of those present, but this is not significant here.)

As you can imagine, even the rather tolerant grammar of English is rather stretched by this sort of thing - while something like 'additionally guest solo performed' is not grammatically incorrect, it is a bit awkward-sounding - and in other languages it is quite possible, perhaps even likely, that there is no grammatically correct way to create a string where the three optional attributes can be dropped in or out without making any change to them.

It is especially likely that there will be no good translation possible when you consider that the actual phrase you want is really 'ARTIST_NAME additionally guest solo performed WORK_TITLE' and there is currently no mechanism to translate this as a string in a different order, e.g. 'WORK_TITLE additionally performed by ARTIST_NAME as guest solo' (or something like that in a language that doesn't have a grammatical sentence structure with SVO (subject, verb [phrase], object) order).

At any rate, when this relationship string is translated, for example into German (as I quickly log into Transifex and check): '{solo:solo-}interpretierte {additional:zusätzlich} {guest:als Gast}' then you get the following four strings:

* solo
* additional
* guest
* solo-interpretierte zusätzlich als Gast

Now the first three strings are still in English - and this is intentional, as they represent the database names of the relevant attributes, which are not affected by localization - and in the UI they will appear alone next to their relevant checkbox and should be translated separately there (in the case of German, into 'Solo', 'zusätzlich', and 'Gast', which is a little bit odd as you might want them to all be in adjectival or Nominal form (German capitalizes all nouns), but it is at least comprehensible and not incorrect).

Of course, when you put the relationship string into context as I noted above, you get 'ARTIST_NAME solo-interpretierte zusätzlich als Gast WORK_TITLE' which sounds not quite right to me, even with my poor German grammar - I would guess that something like "ARTIST_NAME solo-interpretierte zusätzlich WORK_TITLE als Gast" might be more grammatically correct or at least less awkward-sounding, although I'm sure others on this list could correct me.

To get a result like the last, the MBz UI would need to be better internationalized so that the translation string is something like '%1s {additional:additionally} {guest} {solo} performed “%2s”' with a German translation of something like 
'%1s {solo:solo-}interpretierte {additional:zusätzlich} „%2s” {guest:als Gast}' (even including quotation marks, allowing us to localize them as well - although other visual distinctions (backgrounds, outline, or underlining) in the CSS might make quotation marks unnecessary or undesirable in practice).  But this sort of internationalization would require fairly significant changes to the UI (especially since there is a fair bit of HTML - and indirectly, CSS - surrounding various parts of these strings, notably the artist name and work title) so it would be a substantial effort.

Even if it did, there are still other complications - in English the past tense of most verbs is conjugated the same for singular and plural, but this is not the case for other languages - if ARTIST_NAME is the name of a group, the correct German translation of 'performed' would be 'interpretiertet' rather than 'interpretierte' - and other languages (notably Slavic languages like Czech), require different translations for verbs in the past tense depending on the gender (male or female) of performers.  Individual/group pluralization and male/female gender of individual artists are present in the database, but unfortunately group artists are not allowed to have gender, which could be an issue for some languages (I'm not entirely sure).  In any case, getting that information into the localization structure is tricky, and may not be easy or even possible with the current internationalization/localization libraries used by the UI (or the Tranisfex platform itself).

There might already be open enhancement issues for some of these problems, but if not, they could be added.  The specific point (at the top of this e-mail) about stripping the attribute tags from the dropdown strings should definitely be added, though.

@alex


_______________________________________________
MusicBrainz-i18n mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n
Reply | Threaded
Open this post in threaded view
|

Re: attributes in the relationship type dropdown not translated?

Maurits Meulenbelt-2
Alexander Dupuy schreef op 29-12-2013 5:08:
Maurits wrote:
The attributes in the dropdown list on the add relationship page don't 
seem to get translated. Instead of {original:translated} displaying as 
{translated}, it's still {original:translated}.

You seem to have a slight misunderstanding about the (fairly technical) mechanism of relationship types and their descriptive strings.

A relationship string like '{additional:additionally} {guest} {solo} performed' means the following:

* this is a performance relationship
* there are three optional attributes to the relationship
  * 'additional' (which is written in the text string as 'additionally')
  * 'guest' (which is written the same in the text string)
  * 'solo' (which is written the same in the text string)

It's not that {additional:additionally} is in an {original:translated} form (although for reasons noted below, you will see something like that in most translations, so it is not surprising that you interpreted it this way).

Thank you for this thorough reply. I've been struggling with the translation of variables since I started translating and I think I'm not alone.
From a practical point of view, how should I enter the translation of {additional:additionally}? Would {additional|aanvullend:additionally:aanvullende} do the trick?

There are in a way four different strings that need to be translated - the three separate attributes and the entire text string for the relationship (that will be used when displaying a relationship that exists in - or is being added to / removed from - the database):

* additional
* guest
* solo
* {additionally} {guest} {solo} performed

The last (fourth) string is really the one that should be displayed to the user in the dropdown menu - rather than the full relationship string.  The relationship strings need to have the {attribute:text} form for functional reasons (so that the UI can decide whether to include the text or not) but there is really no reason to include the attribute string in the dropdown when an alternate text is provided.  Stripping out the unneeded attribute names can easily be done by a simple regex replacement (after localization, of course) like this: s/\{\w+:/{/ (mixing sed s/// syntax with Perl/PCRE regexp syntax).

I think that the above would be a simple and helpful improvement to the internationalization/localization of the UI.  There are some other problems with relationship strings that I will also mention here, but some may wish to stop reading at this point, since the problems are hard, complicated, and unlikely to be addressed very soon.

One could argue whether the attributes should be displayed in the dropdown in the first place. When you're adding a relationship, you choose it because it corresponds to the relationship you want to add, not because of the available attributes. I can't think of a scenario where you'd pick one relationship over another based on the available attributes (but different users have different needs and wants, so I could be wrong). It just makes the list harder to read. But that's not an issue for this mailing list, I just wanted it off my chest.

The fourth string in a way is actually eight different variants with all the possibilities of additionally, guest, and solo being present or absent.  (Semantically, for this relationship, combining both 'additionally' and 'solo' seems a bit odd, so we might not care so much about the two variants that have both of those present, but this is not significant here.)

As you can imagine, even the rather tolerant grammar of English is rather stretched by this sort of thing - while something like 'additionally guest solo performed' is not grammatically incorrect, it is a bit awkward-sounding - and in other languages it is quite possible, perhaps even likely, that there is no grammatically correct way to create a string where the three optional attributes can be dropped in or out without making any change to them.

It is especially likely that there will be no good translation possible when you consider that the actual phrase you want is really 'ARTIST_NAME additionally guest solo performed WORK_TITLE' and there is currently no mechanism to translate this as a string in a different order, e.g. 'WORK_TITLE additionally performed by ARTIST_NAME as guest solo' (or something like that in a language that doesn't have a grammatical sentence structure with SVO (subject, verb [phrase], object) order).

At any rate, when this relationship string is translated, for example into German (as I quickly log into Transifex and check): '{solo:solo-}interpretierte {additional:zusätzlich} {guest:als Gast}' then you get the following four strings:

* solo
* additional
* guest
* solo-interpretierte zusätzlich als Gast

Now the first three strings are still in English - and this is intentional, as they represent the database names of the relevant attributes, which are not affected by localization - and in the UI they will appear alone next to their relevant checkbox and should be translated separately there (in the case of German, into 'Solo', 'zusätzlich', and 'Gast', which is a little bit odd as you might want them to all be in adjectival or Nominal form (German capitalizes all nouns), but it is at least comprehensible and not incorrect).

Of course, when you put the relationship string into context as I noted above, you get 'ARTIST_NAME solo-interpretierte zusätzlich als Gast WORK_TITLE' which sounds not quite right to me, even with my poor German grammar - I would guess that something like "ARTIST_NAME solo-interpretierte zusätzlich WORK_TITLE als Gast" might be more grammatically correct or at least less awkward-sounding, although I'm sure others on this list could correct me.

To get a result like the last, the MBz UI would need to be better internationalized so that the translation string is something like '%1s {additional:additionally} {guest} {solo} performed “%2s”' with a German translation of something like 
'%1s {solo:solo-}interpretierte {additional:zusätzlich} „%2s” {guest:als Gast}' (even including quotation marks, allowing us to localize them as well - although other visual distinctions (backgrounds, outline, or underlining) in the CSS might make quotation marks unnecessary or undesirable in practice).  But this sort of internationalization would require fairly significant changes to the UI (especially since there is a fair bit of HTML - and indirectly, CSS - surrounding various parts of these strings, notably the artist name and work title) so it would be a substantial effort.

Even if it did, there are still other complications - in English the past tense of most verbs is conjugated the same for singular and plural, but this is not the case for other languages - if ARTIST_NAME is the name of a group, the correct German translation of 'performed' would be 'interpretiertet' rather than 'interpretierte' - and other languages (notably Slavic languages like Czech), require different translations for verbs in the past tense depending on the gender (male or female) of performers.  Individual/group pluralization and male/female gender of individual artists are present in the database, but unfortunately group artists are not allowed to have gender, which could be an issue for some languages (I'm not entirely sure).  In any case, getting that information into the localization structure is tricky, and may not be easy or even possible with the current internationalization/localization libraries used by the UI (or the Tranisfex platform itself).

There might already be open enhancement issues for some of these problems, but if not, they could be added.  The specific point (at the top of this e-mail) about stripping the attribute tags from the dropdown strings should definitely be added, though.

I agree with the points you make here. Even in Dutch, which has grammar almost as permissive as English, you can't just dump four adjectives in front of a noun and expect it to make sense and not sound awkward. Some adjectives are better written together with the noun, others need a suffix. A solution may be to have translatable strings for every combination, but the amount of additional translation work that would provide would be simply frightening.
It would also be better if the linked objects are part of the translatable string, like you wrote, but of course that would mean a lot of work for the developers of the website.

Maurits Meulenbelt

_______________________________________________
MusicBrainz-i18n mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n
Reply | Threaded
Open this post in threaded view
|

Re: attributes in the relationship type dropdown not translated?

Alexander Dupuy-3
Maurits wrote:
Thank you for this thorough reply. I've been struggling with the translation of variables since I started translating and I think I'm not alone.
From a practical point of view, how should I enter the translation of {additional:additionally}? Would {additional|aanvullend:additionally:aanvullende} do the trick?

The word 'additional' here should not be translated, as it is a database name.  I think you have been translating things correctly already; but to be clear, you should translate '{additional:additionally}' as '{additional:aanvullende}' or something like that, where 'aanvullende' (or another adverb) would fit best at that point in the string. You should translate '{guest}' as '{guest:gast}' except for the rare cases where the English word is the same in the target language (e.g. '{solo}' could probably be left as-is in a Spanish translation, and quite possibly in other languages as well, since they are all taking the word from the Italian).

Ian McEwen wrote:
There's several different things out there in this vein; I'll draw
attention to a few things in progress:

a.) the relationship editor uses a partially-interpolated version of the
string in the dropdown -- specifically, it removes all the optional
attributes entirely; I don't remember exactly what it does for the
required attributes with respect to translation, however. Personally, I
like this -- it doesn't make clear every possible option, but in doing
so, it excludes a lot of information that's usually worthless to the
person finding and choosing the appropriate relationship type.

I'm glad to hear that there's some work on this going on.  In that light I wouldn't try to submit a patch for the "quick-fix" that would just strip out the database-name part of the bracket expression when a replacement is given, as it would not be such a quick thing for me in any case.  It might not be a quick fix for a core developer either, but it it were, it might be worth doing if the more complete solution won't be rolled out for quite a while.

I believe that when the attribute name is translated,
something like e.g. {additional} (without an alternate) will use the
translated name even with a binary attribute, but I haven't tested that
directly, and I worked on it a while ago at this point :)

Whether this works or not, I wouldn't advise translators to depend on it, as the attribute name translated by itself is quite likely to be wrong within the context of the relationship string (e.g. in German, 'guest' is translated as 'Gast' - reasonable enough as a label for the checkbox, but dropping a noun into the relationship string where an adverb or adverbial phrase is needed makes no sense - it is better to translate explicitly '{guest}' as '{guest:als Gast}' and this really isn't more work as you are already translating the string anyhow.

d.) contextual issues such as entity pluralizations, genders, and
various other grammatical category are hard in almost every i18n
setting; the basic feedback I've gotten on this is that it's, sadly,
just something that has to be lived with in most cases, and that most
languages can at least choose neutral enough words for
comprehensibility.

This is certainly true.  There are some new technologies that can handle some of these kinds of things a bit better - you might want to check out the client-side translation approach of L20N (l20n.org).  For the translators, there are also exciting new possibilities for translating "in place" so that the context is much more apparent, notably Pontoon from Mozilla Labs (https://pontoon-dev.mozillalabs.com/) that can make it much easier to translate web applications.

@alex


_______________________________________________
MusicBrainz-i18n mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-i18n