During playtesting the translation, I found that text ID 11831 “flip” is used to display the verb_flip in two different contexts: on the light switch and on the toilet paper. How can I have two different words for that in the translation?
I think VERB_OK() might have something to do with it… but since deadline is getting closer, I don’t want to waste time in reverse engineering.
1 Like
I think I had the same problem. It’s flip the paper and flip the switch, but in Italian they don’t match. I think there’s already a topic on that 
but I used a verb that’s kinda OK for both, because having a new verb and changing the code was too much
It was another verb in this case, but also Flip gave us headaches 
No, not Flip!
1 Like
This is always going to be a problem with going from any language to any language. There are some easy ways to make it better, but to fully fix the issue would make the writers life a living hell. As I’ve said before, it’s not even correct English to start with. We don’t say “Open Door”, we say “Open the Door”.
“Flip” is really slang, which is why it gets used on a light switch and toilet paper.
To correctly fix the problem for all languages, every object would need a different flip verb, just to be safe.
That’s what I thought too… but I couldn’t find it.
So thanks for linking it here!
So the question boils down to: can we add unique text IDs?
Just out of curiosity: why are the Enter and Exit verbs split for every object/door then? Did you started doing that, saw it was going to create too much hassle for writers and abandoned it?
(Not complaining though… as it allowed us to at least go through doors in a grammatically responsible way 
)
Not sure I follow?
The text ID’s are attached to the verb, not the object. The attach them to the object would require the text followed the verb. It would make things messy and error prone. You could have a Open verb for two objects and one has a typo.
Doing this seems like the only reasonable way to fix the problem, I’m just not sure (right now) how to do this without adding a lot of day-in day-out for for the programmer.
VERB(flip, TEXT(12345, "Flip")) { ... }
During the core of dev, it wold be a little easier with:
VERB(flip, "Flip") { ... }
Is this the only big issue with translations?
Actually, we can still initially code using
VERB(flip) { ... }
and run a python script before translation extractions that creates
VERB(flip, "Flip") { ... }
So this might be pretty easy.
2 Likes
I meant that now there is a separate ID used with verb_use_text and verb_use_desc for each door. Which in practice attaches the text ID to the door object, rather than to the verb (Leave/Enter)
But in doing that, you also introduced a bit of duplication (and possible typos where you may Leave one door and Laeve another).
For “flip” (and all other verbs), the ID is indeed attached only to the verb - for good reasons.
I was simply wondering why you chose a different approach for doors compared to all other objects.
Of course not… but it is not a big issue. It can be annoying at times, but we fixed it in the most creative way imaginable. By reverting to “flip” for both 
I was thinking what could be useful for translators is to get the context for the object in the tsv file, just like we have for the location now.
Something like:
ID tr en loc obj
12345 Toggle Flip Bathroom.Dinky light switch
67890 Turn around Flip Bathroom.Dinky toilet paper
So what was the biggest issue with translation? How can I (realistically) make your lives easier in the future?
Let’s summarize:
- for each object, you have a verb list.
- A verb used for an object (e.g. FLIP PAPER) could not sound right (when translated into another language) for another object (e.g. FLIP SWITCH).
There could be a default translation list, written somewhere, for each verb.
For example (in italian):
Open → “Apri”
Close → “Chiudi”
Flip → “Gira”
… with the possibility to override the default translation, for a particular object.
For example:
VERB(ID_TOILETPAPER, ID_FLIP) //uses default translation "Gira"
VERB(ID_SWITCH, ID_FLIP, "Accendi") //Overrides "Gira", uses "Accendi"
The above are only a prototype. They could be entries in a text file, or something else.
Your thoughts?
I think the best solution would be having contexts when showing it.
FLIP has a VERB_ID and a translation in each LANG for but when the engine needs to show the text, instead of looking for translation of VERB_ID in LANG, it first checks if there’s an entry for VERB_ID, OBJ_ID in LANG. If so, it shows the overridden translation, if not it shows the simple VERB_ID translation.
So kinda like what @ZakPhoenixMcKracken proposed.
Isn’t all that solved with just doing
VERB(FLIP, TEST(12345, "Flip")) { }
Every “flip” verb would have a different id (12345) so it can be tailored to the object and situation.
Each object will have it’s own (possible) translation of each verb? My main concern is speed of development. I need something that is fast for the initial programers to do (without wacky keyboard and editor macros), but then gives the translators the power they need to do a good translation.
Yes, the result is the same: for a particular object, there’s the possibility to specify a different text to show, in place of the default string.
So:
VERB(FLIP, TEST(ID_PAPER, "Flip")
VERB(FLIP, TEST(ID_SWITCH, "Flip")
ID_PAPER and ID_SWITCH are constants, e.g. 12345 and 12346.
Then, the “TEST” function, what should it do?
I’m just concerned about how the verbs are associated to the objects. I’ve seen in the code that you have like “turn on / turn off” added automatically to objects that have two states called on and off.
Would these objects (or, the verbs) get a new macro ID also? If so, then it’s OK. Otherwise, it’s kinda like the article “a” that was added automatically to the photo descriptions.
To recap, if all instances get a different ID, then it’s fine (just a bit annoying for the translator, like the “a” article that we had to translate differently on every instance).
If not, we’ll have the same problem as some things like a faucet don’t get turned on in Italian, but opened and closed.
Just to be clear: all of this is for a future game/release and not for the translation deadline of today. Right?
Another example is verb_puton. It seems its only use in Delores is with the stamps. (Although there is also some puton_hat in the animation code). Since ID 11585 is given without context… this one of the things that most translations got wrong. At least mine did - after being correctly translated as “stick” and play tested, I came across it again during a review and changed it thinking “Put on” should not be translated as “stick on”?!
So @RonGilbert , I hope you’ll still accept tsv updates today?
Yes, for a future game.
If I end up doing VERB(flip, "Flip") { ... } I will add the associated object in the translation .tsv file so the translator knowns what object is being “flipped”.
2 Likes
If all that is being changed is the .tsv file there is some flexibility for getting those past today, but not code or art. Once open beta starts I might relax those rules based on what “bugs” come in. But for now, I need stability to make the first build.
I was hoping to get that done today, but I’m having issues with Steam and since it’s a holiday in the US, no one at Value is working. It might be Wed before I get the first build posted.
2 Likes
Awesome! Good luck!
(and thanks for accepting my PR in the nick of time)