I agree. Furthermore, there should be an option transliteration lyrics (IE: Japanese lyrics written in Romaji rather than Japanese script)

Benji99: I think you've misunderstood what this ticket is for. It's about the language the lyrics are sung in. How they're written down depends on the release the song is used on (a work can be used for numerous recordings on numerous releases).

+1 This would make works much for useful!

OK for a language but I disagree on using this to determine if it's an instrumental because I call this a hack.

What would we do with scat songs ?
These are sung (→not instrumental), but no language.
So we would set them not as MBS-2766 type instrumental (either song or new type "scat").
And set the MBS-1798 language as "none".

For instrumental we need a new type (MBS-2766), not hacking this new language attribute.

But the "instrumental" is orthogonal to all other types, isn't it? Every current work type can either be instrumental or not, so it is wrong to add it as new type. If the language hack really isn't sufficient (I personally haven't thought about songs with vocals but no language), it should be an attribute of the work (like language), but not a new type. What do you think?

It'd be great if multiple languages could be specified. I can think of a few examples where more than one language is used on the same track.

Please an admin unlink MBS-2766 as it is unrelated.

I support the idea of implemeting MBS-3296 instead of this. With the dynamic work types we could simply create an attribute "lyrics language" among a whole bunch of things that would make works finally useful.

Will MBS-3296 let us use other tables in the database as a list of possible values for that attribute then?

Setting due date based on when this task was moved to 12mo bucket.

As per http://blog.musicbrainz.org/?p=1301 :

I'm not aware of any objections to storing the lyrics language of a work. This ticket has a number of votes and comments, so I'll take that to mean there is a consensus that we should implement it in some form.

My proposal is:

We should be able to specify a language for a work which will represent the primary lyrics language. The available languages should be taken from the existing language table. As with release languages, the ISO 639-2/T code (language.iso_code_3t) should be used when displaying the full name of the language isn't desirable (e.g. in the WS or where space is limited).

The language should be settable from the add work (/work/create) or edit work (/work/MBID/edit) page.
The language should be shown as part of the add work and edit work edits when the language is being added, edited or removed.
The language should be shown on the work page (/work/MBID) in the sidebar.
The language should be shown in the works table for an artist (/artist/MBID/works).
The language should be returned in any relevant WS queries (e.g. anywhere that other work attributes such as ISWC or type would be included should also include the language)

I don't know what supporting documentation, if any, would be needed.

Notes:

1. I don't think we should implement multiple languages right now since it's more complex and opens up more issues. That doesn't mean we can't do it later on (once we have some actual experience dealing with such cases). The upgrade path for such a change in the future (once we know how we want it to work) should be fairly straightforward. This is also consistent with how we currently handle release languages.

2. Whether or not zxx should be used for instrumentals is an issue for the style list.

3. Support for multiple languages, Picard support and any improvements to the display should be given separate tickets if this is accepted as it is.

4. This would be best implemented alongside MBS-1799, but does not depend on it.

I completely agree with this ticket.
About showing the language of work. It would be very useful to show the work's language also:
1) on the release's page (/release/MBID) for the recordings on the work's title line in brackets after the title itself:
performance of: Work Title (Language)
2) on the recording's page (/recording/MBID):
in the section "Relationships":
performance of: Work Title (Date, Language)
or in the section "Related works" as a line after writer's line(s):
language: Language

I agree that a way to set a language for a Work is important, but I also agree with T Dilation that one language will sometimes not be enough.

Also, Robert's idea of implementing it as dynamic attributes is elegant, but Nikki is right that it should be used only if dynamic attributes values can be limited to the values from a reference table.

This ticket is under consideration for the May 15h schema change release. However, it is under specified at this point in time. In order to keep this ticket in consideration for the release, please do the following:

• Specify exactly what the user interface changes will be. Mock ups would be great. Due date: April 2
• Specify exactly what the database changes will be. We will need to have an exact database table change proposal. Exactly which columns will be added/removed/modified and what new tables will be created. If you cannot specify the changes to be done, chase down a developer to specify them for you. Due date: March 26
• This ticket is considered contentious and requires more community review. I will post a blog entry highlighting this ticket for more review.

User interface changes: Copy the display of "Type" in all the places I already specified.

Database changes: Add one column to the work table (call it whatever you like). Add a foreign key linking the new column to language.id.

I think this would be a useful addition, I've been doing this with tags vocal-lang-* up until now, see e.g. this song in Mandarin and Cantonese:
http://musicbrainz.org/recording/3303f828-d459-4d81-a3c1-bc41413900db
http://musicbrainz.org/recording/0945051f-4c02-4019-9386-08b18543e7dc

These are also recordings that I've tagged as being in multiple languages, e.g. http://musicbrainz.org/recording/0abc13b3-06aa-44ec-82fd-d16cb98a040c

For at least Chinese, ISO 639-3 is a must, since the distinction to be made is between Mandarin, Cantonese and Taiwanese, not between the writing systems (simplified or traditional Chinese).

Chinese is exactly what I was thinking of when I said this would be best implemented alongside MBS-1799. I already included those three when I was listing some codes to enable straightaway, if you have any more it would be best to add them to that ticket.

Note that as an interim solution for multiple languages, the ISO 639-2/-3 code "mul" for multiple languages can be used, just as it is for track listings.

I don't think this necessarily needs to wait for the dynamic attributes. Migrating it later should be easy enough.

If nikki is suggesting the following:

ALTER TABLE work ADD COLUMN language INTEGER;
ALTER TABLE work ADD CONSTRAINT work_fk_language FOREIGN KEY (language) REFERENCES language (id);

Then this seems fine.

This ticket is in danger of being rejected from the upcoming schema change release. Please provide UI mock-ups today.

As nikki already said earlier: "User interface changes: Copy the display of "Type" in all the places I already specified."

Those places are:

The language should be settable from the add work (/work/create) or edit work (/work/MBID/edit) page. (so, dropdown like the Type one)
The language should be shown as part of the add work and edit work edits when the language is being added, edited or removed. (so, as with Type)
The language should be shown on the work page (/work/MBID) in the sidebar. (so, as with Type)
The language should be shown in the works table for an artist (/artist/MBID/works). (so, as with Type - although I guess the table is a bit crammed, but a two/three-letter column for language codes should be enough if there's no space)
The language should be returned in any relevant WS queries (e.g. anywhere that other work attributes such as ISWC or type would be included should also include the language)

I feel this ticket is well defined (in terms of the DB and the UI) to be included as is.

How will this be shown in the web service? Will we use a <language> element, which has previously been for the language of written text rather than content, or do we introduce a new element?

Searching for work by language is failing with stack trace ,

http://test.musicbrainz.org/search?query=lang%3Ajpn&type=work&limit=25&method=advanced

gives

Attribute (language) does not pass the type constraint because: Validation failed for 'Language' with value "jpn" at constructor MusicBrainz::Server::Entity::Work::new (defined at lib/MusicBrainz/Server/Entity/Work.pm line 84) line 87
MusicBrainz::Server::Entity::Work::new('MusicBrainz::Server::Entity::Work', 'HASH(0xc895318)') called at lib/MusicBrainz/Server/Data/Search.pm line 593
.....

(underlying search works correctly http://test.musicbrainz.org/ws/2/work/?query=lang:jpn)