Korean translation ongoing.

[EdogawaKun]

Added some Korean translations. Still WIP, and need to figure out some punctuation differences for some phrases.

[cliss]

Hey, @EdogawaKun. I actually shouldn't have approved this — my fault! — there were a couple issues here.

1) You seem to have made a new ko.xcloc within the existing ko.xcloc. I'll fix this. 2) It looks like you stripped a lot of the placeholders. Take this English string for example:

No results found for "%@"

This will actually be shown in the app as:

No results found for "Somemoviethatdoesntexist"

Your translation is:

일하는 결과를 찾지 못했어요.

Which according to Google means:

I didn't find any results that worked.

That does work, but generally speaking, and where possible, I'd prefer to keep the placeholder. So, again using Google, perhaps something like this:

"%@"에 대한 검색결과가 없습니다.

I don't know anything about Korean, so maybe that's semantically weird/wrong. But generally speaking, I'd prefer to keep the %@ placeholders wherever possible.

[EdogawaKun]

Hey @cliss,

For issue 1, that's my bad — it's been quite a while since I've used git in general, so I think the versioning got screwed up as I was working off older one. (I did study CS in college, but am no longer a developer 😅) As I'm still working off of the old version, I think I'll probably do a manual merge of copy and pasting strings after I'm done with the initial translation.

For issue 2, this was something that I was about to ask you. I'm not sure if you've seen my comment on the matter, but in Korean there are few suffixes where a different syllable is put depending on the last syllable of the previous word.

In terms of your example, that's the translation that goes around the issue, so it should work. However, there were other strings that I found particularly problematic.

One of those was Find movies where %@ worked with: string.

In Korean, that would roughly translate to %@과 함께 작업한 영화를 찾아보세요 if we respect the placeholder. However, 과 is not always used.

For example:

• In Korean, Sam Neill is written as 샘 닐. In this case, 과 is used. (i.e. 샘 닐*과* 함께 작업한 영화를 찾아보세요.)
• However, Steven Spielberg is written as 스티븐 스필버그. In this case. 와 is used. (i.e. 스티븐 스필버그*와* 함께 작업한 영화를 찾아보세요.)

In the old days of translation, we compromised by putting both of the suffixes in the translation. (i.e. 샘 닐*와(과)* 함께 작업한 영화를 찾아보세요.) However, these days, this method is now seen as a very old way of translation, and makes the translation look dated. I've heard there are now algorithmic ways of solving this, but since I cannot suggest that because of few translation issues on one language, after few hours of thoughts, I compromised by taking out the placeholder entirely. I thought that given the context in the menu, having no placeholder should not be an issue with the overall UX, either.

As you've found on No results found..., there may be a way to go around this. One way that I'm thinking is somehow putting the placeholder at the rear end of the translation, so that we need no suffixes. I'll still have to make the sentence (maybe not even a direct translation) in a way so that could be a possibility, but in the meantime, I wanted to hear your opinion on this. (as you may have guessed I was stumped by this for a while 😂)

Hey, @EdogawaKun. I actually shouldn't have approved this — my fault! — there were a couple issues here.

1. You seem to have made a new ko.xcloc within the existing ko.xcloc. I'll fix this.
2. It looks like you stripped a lot of the placeholders. Take this English string for example:

No results found for "%@"

This will actually be shown in the app as:

No results found for "Somemoviethatdoesntexist"

Your translation is:

일하는 결과를 찾지 못했어요.

Which according to Google means:

I didn't find any results that worked.

That does work, but generally speaking, and where possible, I'd prefer to keep the placeholder. So, again using Google, perhaps something like this:

"%@"에 대한 검색결과가 없습니다.

I don't know anything about Korean, so maybe that's semantically weird/wrong. But generally speaking, I'd prefer to keep the %@ placeholders wherever possible.

[cliss]

Continuing this conversation in #127