Re: attributes in the relationship type dropdown not

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

Re: attributes in the relationship type dropdown not

Ian McEwen
translated?
Reply-To:
In-Reply-To: <[hidden email]>
Errors-To: [hidden email]
X-Operating-System: GNU/Linux x86_64 3.12.1-3-ARCH
X-Editor: VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 10 2013 20:25:48)
X-Accept-Primary-Language: en
X-Accept-Secondary-Language: de
X-Accept-Tertiary-Language: eo
X-Google-Loop: groups

On Sun, Dec 29, 2013 at 05:08:08AM +0100, Alexander Dupuy wrote:
> 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.
>

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. The plan,
such as it is, is already to do this at some point, but probably the way
that'll happen will simply be to add relationship-editor-type interfaces
to other entities, add URL support, and ultimately phase out the
individual add-relationship pages.

b.) as you point out, the whole relationships system is rather hard to
translate at present. One weakness I don't think you included is that
there's currently no syntax for some text being dependent on multiple
attributes at once. The current best idea for this, and many of the
other issues (though not the one that involves reordering where the
entities themselves appear) is simply to include the strings for
translation *after* interpolation. It results in many more strings to
translate, but for highly synthetic languages like german, it makes it
much easier to create all the appropriately mushed-together words :).
I'll note that I'm not too concerned about the reordering problem for
one major reason, which is that the long string isn't actually used for
display on the site very many places; most places we use the shorter
forms like "performed drums, guitar, piano: <entities>" (or so) instead,
which due to their table-like display structure can't really operate
with a different format like the long strings can.

c.) the things about names of attributes (and link types, in fact) are
somewhat complicated; we tend to address those by name, as you mention,
but they do also have MBIDs, and some of them are still translatable
(link types, I recall, are not, but attributes are -- instrument names,
for example, are attributes, and are certainly not translated in each
link phrase independently). The bracket syntax behaves slightly
differently, therefore, with two types of attributes: binary ones, like
those you mention (additional, solo, etc.) work as you describe, but
multi-valued ones such as instrument and vocal will pull in a
comma-separated list of the translated attribute names. I believe the
translated names are also used in the attributes section of the add
relationship page. 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 :)

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.

Hopefully that's at least marginally clear.

> @alex
>

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


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

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: attributes in the relationship type dropdown not

Ian McEwen
translated?
Reply-To:
In-Reply-To: <[hidden email]>
Errors-To: [hidden email]
X-Operating-System: GNU/Linux x86_64 3.12.1-3-ARCH
X-Editor: VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 10 2013 20:25:48)
X-Accept-Primary-Language: en
X-Accept-Secondary-Language: de
X-Accept-Tertiary-Language: eo
X-Google-Loop: groups

On Sun, Dec 29, 2013 at 02:26:34PM +0100, 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?
>

Note that the relationship bracket syntax is different from the others.
However, in general you probably want to translate
{additional:additionally} as {additional:<translated equivalent of
'additionally'>}. In the relationship bracket-syntax, | is used for "if
the attribute is *not* true". That is:

{additional} is the same as {additional:additional}, which is the same
as {additional:additional|}, and will display
'additional' (or its translation, as I note in the other email) when the
'additional' attribute is true, and nothing otherwise.

{additional:additionally} is the same as {additional:additionally|} and
displays 'additionally' when the 'additional' attribute is true, and
nothing otherwise.

{additional:additionally|primarily} (contrived example) would display
'additionally' when the 'additional' attribute is true, and 'primarily'
otherwise.

An example of the third syntax is the librettist/libretto translation
rel, which has: '{additional:additionally} {translated:translated|wrote}
the libretto for'

> 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.
>

I agree, as I mention in the other mailing list this is what the
relationship editor does, except in the case of required attributes,
which it does include.

--
Ian

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

attachment0 (205 bytes) Download Attachment