How are the translations accessed?

[andy5995]

I see there are translations in master/translations, but I don't see them accessible from the website. How are they accessible or is that a planned feature?

[snshn]

It's a planned feature, exactly that. One way to do it would be to replicate the structure of the database/ directory exactly, but also prepend language name (e.g. "American English" instead of en_US); then in build.py there could be some code to build those pages, and then add links to those translations from the untranslated page with lyrics. What do you think?

[andy5995]

I think if we could get without using the country code, that would be better. GNU coreutils seems to do it that way:

With some exceptions (pt_?? for example)

Also, it seems omitting the CC is pretty standard.

andy@oceanus:/usr/share/locale$ tree de | wc -l
528
andy@oceanus:/usr/share/locale$ tree de_AT/ | wc -l
5
andy@oceanus:/usr/share/locale$ tree de_CH/ | wc -l
8
andy@oceanus:/usr/share/locale$ tree de_DE | wc -l
8

[andy5995]

It's a planned feature, exactly that. One way to do it would be to replicate the structure of the database/ directory exactly, but also prepend language name (e.g. "American English" instead of en_US); then in build.py there could be some code to build those pages, and then add links to those translations from the untranslated page with lyrics. What do you think?

I thought of a few other options as well. So from this point:

Nicole/
├── A Little Peace
│   ├── A Little Peace
│   ├── Butterfly
│   └── Where Have All My Heroes Gone
├── Butterfly
│   ├── Butterfly
│   └── Where Have All My Heroes Gone
├── Ein bisschen Frieden
│   └── Ein bisschen Frieden
└── Papillon
    └── Papillon

I'm thinking of something like

Nicole/
├── A Little Peace
│   ├── A Little Peace
│   ├── Butterfly
│   └── Where Have All My Heroes Gone
     └── de_A Little Peace
     └── it_A Little Peace
     └── de_Butterfly

or those 3 would go into a "translations" directory under the Album. Downside to that is you could potentially wind up with a "translations" directory for every album. But downside to what I illustrated above is a lot of language files in the same directory as the original lyrics files.

This might be worth considering:

Nicole/
├── A Little Peace
│   ├── A Little Peace
│   ├── Butterfly
│   └── Where Have All My Heroes Gone
     └── de/A Little Peace
     └── de/Butterfly
     └── it/A Little Peace

There you'd wind up with a better balance I think, of directories and files, even if you had an album with many tracks and many translations. But if you had one lyric file translated into 30 different languages, you'd again wind up with many directories in the same directory.

In any case, it might be most efficient to add info about existing translations to the lyrics file. For example, if there's a line on the lyrics for "A Little Peace" such as "Translations: {fr,de}", the build generator will look for the translation, do a check to make sure the file exists, return an err if doesn't (for testing) and create the static pages, and substitue "{fr,de}" with an actual link.

Anyway, I hope I could give you some helpful ideas to work with.

[snshn]

Your propositions are very interesting. Here's what I currently have, but your idea with appending language to the file name or as an additional directory could have many benefits, will look into it more later today.

[snshn]

Made a modification, now it's translations/<letter>/<artist>/<album>/<language>/<recording>... and I'm realizing that it adds one more directory to the depth, plus will require to type the name of the recording for every newly added translation... and if that name gets corrected in the database/, then one would have to go through every directory, correcting the name there...

Perhaps, it should be translations/<letter>/<artist>/<album>/<recording>/<language>? Pretty much almost exactly what you proposed as the last option in your comment above. I don't think it's a big downside that there will eventually be thousands of files named "American English" and "French", as when copied, they could easily be renamed... that would make the maintenance much less tideous

[snshn]

I'm also thinking that perhaps the name of the song should be translated as well? Then having translations/<letter>/<artist>/<album>/<language>/<recording> would make sense.

[andy5995]

I'm also thinking that perhaps the name of the song should be translated as well? Then having translations/<letter>/<artist>/<album>/<language>/<recording> would make sense.

I think if people are looking for a translation to a song, they will search by the original title. Also, if there's a link on the song lyrics page to the translations, the title doesn't need translating (additionally, most likely the title will be within the song text and translated there).

But one reason it "can't" be done: Sometimes the same artist releases a song in one language, then a version of that song in another language. For instance, the song "Ein bißchen Frieden" by Nicole was released in several languages (by Nicole), and each time the lyrics were rewritten to match the melody of the original German version. The literal translation of "Ein bißchen Frieden" to English is "A Little Peace", but the English version of the song "A Little Peace" is not a literal translation of of the lyrics for "Ein bißchen Frieden".

Another example is the German song titled, "Papillon" (also by Nicole), which is actually a French word for 'Butterfly' ('Butterfly' is "Schmetterling" in German) 'Papillion' is French for "Butterfly". Title aside, it's another song where multiple versions were released. The English version is called "Butterfly". The song was released in Dutch as "Papillon [Nederlands]" and French as "Papillon [français]".

(I've been rewriting the Wikipedia page for this artist the last couple weeks ;) )

So this is an usual situation. Most artists don't do that as far as I know. An example of a more well-known song is Nena's "99 Luftballons". Later released as "99 Red Balloons". But in that case, the English title isn't a direct translation.

The Beatles did 2 songs in German. "Sie Liebt Dich" (She Loves You), and "Komm, Gib Mir Deine Hand" (I Want to Hold Your Hand).

[snshn]

You're making a good point about users looking for translations by looking for files with original (untranslated) names. It's even better for when the database is being used not through the web UI but via filesystem or some other software. Can't be 100% sure about the title being within the text of the translation all the time, but we could always use additional meta keys along with specifying what language it's translated into (e.g. Localized name, and even maybe Localized album).

Interesting story about the "Butterfly" and "A Little Peace". Let's try to figure out some structure that would accommodate all those examples, would be a shame having to move around hundreds of songs later if anything needs to be changed. We could try to design it in reverse: make up two relational database tables, "lyrics" and "translations", and think of what columns they need, what relations they must have to e.g. make a website or app work, and then try to see what kind of structure should be used on the filesystem level to make it easy to parse from fs into sql.

[snshn]

@defanor also has an interesting idea about mapping translation files to their original texts on the website

[defanor]

@defanor also has an interesting idea about mapping translation files to their original texts on the website

I don't think such mappings would affect the directory structure though: they can mimick it, can be embedded into translation files, and there's a few other options, but somehow we'll sort it out. A slightly more tricky issue when it comes to creative translations is that there can be multiple variants of those, unlike it is with software translations, so we'd have to decide how to store multiple options.

[snshn]

I've been thinking a lot about this issue. There're no variants when it comes to lyrics files here — thanks to git and GitHub's PRs; just lots and lots of revisions, with only one final version that contributors have agreed upon (what's in master).
As a remotely similar example, translated books don't have versions, but they do have editions (which are essentially revisions). I'm thinking that "versions" could be forks in this case, e.g. somebody else makes a fork of this project, and starts pulling lyrics from here to their repo... they could correct something and moderate it the way they desire, and that will be the alternative version of lyric text or translation.

[snshn]

How about translations/<letter>/<artist>/<album>/<original-recording-name>/<language>/<translated-recording-name>? With a test in place to ensure there's only one file in the final (deepest) directory?

[defanor]

Surely book translations do have different variants, usually by different authors. Those are derivative works, but still distinct from the original and from each other (copyrighted separately, too). And I'm not sure if it's a good idea to restrict the database to just a single version, since there can be rather different interpretations, leading to different translations.

[andy5995]

Surely book translations do have different variants, usually by different authors. Those are derivative works, but still distinct from the original and from each other (copyrighted separately, too).

I think in those cases they are translations of books in much older languages, which makes it more difficult to determine the author's original meaning (and therefore more translations). I was reading a book on the evolution of language a while back. What was known as English 1000 years ago would be unrecognizable today

https://www.google.com/books/edition/The_Unfolding_of_Language/maz9oLIKZKkC?hl=en&gbpv=1&pg=PT64&printsec=frontcover

I think it would be pretty rare that there would be significantly different interpretations of one song. And what would the criteria be for having alternate translations? Someone thinks one word 'must' be changed? Five words? 20? And how would it be decided when an alternate translation gets created or change an existing one? I think for that you'd need to have at least 2 or more people who are able to translate between languages, and they'd have to come to some kind of consensus. Otherwise you'd just have people randomly popping by and submit a PR because they feel like a different word would be better.

And I'm not sure if it's a good idea to restrict the database to just a single version, since there can be rather different interpretations, leading to different translations.

I think a restriction like that may be a practice solution, but I also think if there is a rare case where someone suggests that a radically different version is needed, it could be done.

And if there are multiple translations for a single song, why not just "translation-1, translation-2, translation-3" all in the same directory?

cc @sexybiggetje

[snshn]

The sad fact that things get forgotten and it becomes harder to translate them as decades go by is one of the main reasons this project was created — it's a shame to see lyrics rot away without maintenance, I view this repo more as a digital museum of sorts.

There could be for sure more disagreements when it comes to translating things. People tend to hear different things within songs as well — depending on the equipment they have, what languages they're familiar with, how good their hearing is, etc — so adding the task of translating something on top of that is likely going to make it even tougher for people to agree on what the text should be.

I worry that allowing to have an infinite stack of translations will lead to piling up of files — which nobody would want to ever remove from (not to offend the contributor or lose possibly the only correct translation). I believe git takes care of versioning, by storing history of changes that is easy to find and go through for every file in the database. GitHub has Discussions, Issues, and PRs where people can easily communicate and agree upon what version is considered to be correct... it's really the problem of precise science meeting art, so using logic is only good as long as something can be proven... I'd say having those discussions regarding translations is more beneficial to contributors as a social and learning thing, rather than just letting everyone add their version and then somehow fight for the right of making their version the default / first one.

[defanor]

I think in those cases they are translations of books in much older languages

Not necessarily: I think it's common for anything considered classical, and for merely relatively popular books. Checked now, even the contemporary The Hitchhiker’s Guide to the Galaxy has different translation variants. Though book translations are a bit off-topic here.

And what would the criteria be for having alternate translations?

The criteria likely won't be something technical, such as the number of words, but rather based on different interpretations or styles, and possibly on license restrictions if we'll be collecting independently composed translations. Actually that looks like an important decision to make: whether to include a translation service into this project (and edit translations within it), or to focus on collecting them, with only light edits (as with lyrics themselves; and possibly editing in a separate-but-related project). I think attempting to have a single version would work better with editing, while multiple versions may work better for collection.

And if there are multiple translations for a single song, why not just "translation-1, translation-2, translation-3" all in the same directory?

Sure, that'd work.

[snshn]

I don't think book translations is off-topic — to me that looks like a good example of a very similar solution that everyone is familiar with. By different books we could assume different repos, and just accept the fact that somebody out there will have a different lyrics database with different translations... with neither of them being right or wrong (there's no wrong or right when it comes to art, unless it's a really obvious mistake).

Putting translations into a different repo sounds like another thing that could benefit the project.

"translation-1, translation-2, translation-3" all in the same directory?
I'd say that's way too /proc, I love all those UNIX-like things and all, but that seems to bear very little information... everything else in the database right now seems to be intuitive and easy to read and find, name "translation-1" bears no useful information, not to mention intuitively most people will think that translation-1 is the main/default one, and the rest are just attempts to correct it.

[andy5995]

I don't think book translations is off-topic — to me that looks like a good example of a very similar solution that everyone is familiar with. By different books we could assume different repos, and just accept the fact that somebody out there will have a different lyrics database with different translations... with neither of them being right or wrong (there's no wrong or right when it comes to art, unless it's a really obvious mistake).

Putting translations into a different repo sounds like another thing that could benefit the project.

"translation-1, translation-2, translation-3" all in the same directory?
I'd say that's way too /proc, I love all those UNIX-like things and all, but that seems to bear very little information... everything else in the database right now seems to be intuitive and easy to read and find, name "translation-1" bears no useful information, not to mention intuitively most people will think that translation-1 is the main/default one, and the rest are just attempts to correct it.

I meant more along the lines of "[song-name], [song-name]-2, [song-name]-3", but I get your point about

most people will think that translation-1 is the main/default one, and the rest are just attempts to correct it.

[snshn]

Just found this website, I believe they have a pretty interesting approach that's worth taking note of: https://lyricstranslate.com/en/acdc-lyrics.html

[snshn]

I merged the current work on this, we can improve it later. We can continue the conversation here or in a separate thread.

[snshn]

https://lyrics.github.io/tr/ is the current index of available languages.