maxim-zhao / psrp

Phantasy Star Retranslation Project
http://www.smspower.org/Translations/PhantasyStar-SMS-EN
65 stars 10 forks source link

(Feature Request) Implement <players> token for possessive form of name #74

Closed gensakudan closed 2 years ago

gensakudan commented 2 years ago

Appending a possessive suffix to a word is a little different in German than it is in English, where you can generally get away with just using 's for everything (unless it's a plural word, but those aren't an issue in this project).

In German, the possessive suffix is normally just s. However, if the word in question ends with an S or S-like sound (e.g. X, Z, or even -ce as in "Alice"), then ' is appended instead. What this means for this particular translation is that Lutz becomes Lutz', and this exception has to be accounted for.

My proposal is a token such as <players> or <player's>, which would essentially be the possessive alternative to the <player> token. To that extent, player names would have their respective possessive suffixes in curly brackets, e.g. Alisa{s}, which <player> would print as Alisa and <players>/<player's> as Alisas.

In other words: <players> ignores curly brackets and what's between them, and <players>/<player's> outputs the name as well as what's within any curly brackets.

maxim-zhao commented 2 years ago

Does the same apply to monsters? We have 11 possessives in English:

   en: <Article><monster> dodged <player>’s attack.<delay>
   en: <player> dodged <article><monster>’s attack.<delay>
   en: <player>’s spell had no effect.<delay>
   en: <Article><monster>’s spell had no effect.<delay>
   en: <Article><monster>’s attack was deflected by the magic wall.<delay>
   en: <Article><monster>’s spell was deflected by the magic wall.<delay>
   en: <player>’s stamina was restored.<delay>
   en: <Article><monster>’s stamina was restored.<delay>
   en: <player>’s bindings came apart.<delay>
   en: <Article><monster>’s bindings came apart.<delay>
   en: <Article><monster>’s eyes are blank.<delay>

I presume the possessive form could be totally different in some languages too...

gensakudan commented 2 years ago

See the other issue I opened for what to do with monster names. Like player names, they have their possessive suffixes in curly brackets, but whether to use the possessive form or not depends on the case token that comes before the monster token, which would completely replace the <article> token in these instances.

maxim-zhao commented 2 years ago

If for monsters we have a <gen> tag that triggers use of the {} wrapped text, how is that different than using <gen><player>?

gensakudan commented 2 years ago

The way I had it in mind, the <gen> tag is also directly responsible for printing the article before the word, which player names don't have or need. Then again, what you brought up wouldn't be any different from doing the same thing with <gen><monster> with an enemy name that doesn't have an article (e.g. Lashiec), so implement it however is more convenient to you.

maxim-zhao commented 2 years ago

Ideally we'd pick a suitable word for <gen>, e.g. <des>, which would "read" better in the script, like Der Zauber <des><Monsters> hatte keinen Effekt. - for similarity to other languages. However this is optional, it's just tokens for the script processor to replace.

gensakudan commented 2 years ago

I was going with the assumption that using <der><des><dem><den> for the case tokens would conflict with the <der> token used in enemy and item names, but if that's not an issue in your book, I agree it could be done.

maxim-zhao commented 2 years ago

They're technically orthogonal (literally, rows vs columns in the table) - one gets encoded into the script and one gets encoded into the "item". So they don't need to avoid overlap. Again, technically, the item ones get encoded from the .tbl file but the script ones are handled in the Python encoding script.

gensakudan commented 2 years ago

Judging by the screenshot provided in this response, it seems that this feature has been implemented, so I suppose it's safe to close this issue.