Post by Alexander DupuyPost by MauritsThe 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}
* 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?
Post by Alexander DupuyThere 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
* 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
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.
Post by Alexander DupuyThe 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
'{solo:solo-}interpretierte {additional:zus?tzlich} {guest:als Gast}'
* 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
<http://en.wikipedia.org/wiki/Czech_verb#Participles>), 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-i18n/attachments/20131229/105b42d7/attachment.htm