Stringtable / Translation Issues

[Geoff the Medio]

I understand your proposal. It will work with any language I suppose, the only important thing is to make it felxible enough, so the translator can extend the number of stringtable entires.

You do not seem to understand. You will not be able to add extra stringtable entries. You would be able to make a stringtable entry that changes itself depending what flags are checked for by the string into which it is passed.

Things that start with $'s, like $EMPIRE_CITIZEN are not stringtable entries. These are parameters in another string. Another, differently named, stringtable entry would replaced something starting with a $ in a string. The stringtable entry that replaces a particular parameter cannot be changed by a translator; which entry is used is fixed in the game code.

By making a stringtable entry mutable, the string into which it is passed can pick from various separate strings in the stringtable entry that have particular flags attached, allowing the appearance of the one stringtable entry to change depending on what it is passed into.

[Blade Runner]

OK. I understand now.
What I propose is the next:
Every stringtable entry will contain two parts. The first part is for the system to pick up the right kind of sting, like $EMPIRE and the second part which tell the system exactly which kind of string must be picked.
An example:
Stringtable entries for English:
.
.
EMP1 $EMPIRE* = Toolver
EMP1 $EMPIRE*S = Toolvers
.
.
EMP2 $EMPIRE* = Kutaful
EMP2 $EMPIRE*S = Kutafuls
.
.
etc.

When the system put the sentence on the screen, it will first look for the right empire (in this case let say EMP2), which will came from the code. Than the system will check the sentence:
"Sdf skd ksjdh ksjdfh ksjdh $EMPIRE*S ksjh ksh skh" so it will pick up the right string ($EMPIRE*S is Kutafuls) and replace it to the sentence into the right position:
"Sdf skd ksjdh ksjdfh ksjdh Kutafuls ksjh ksh skh"
I admit this system is more complex than a rigid stringtable construction, but it is easy enough to implement without too much added work. This way the translators can add their important modifications, without any programmers interference.
If any programmer has a problem to implement it, I can quickly write a short code in Delphi, which will show how to do it.

[Geoff the Medio]

The syntax aside, your proposal looks roughly equivalent to the case of my suggestion where one string has multiple forms that are chosen between based on the context of the string into which it is passed.

However you don't cover the case where a string is modified based on the information contained in a string that is passed into it. For example,

"I like $NAME. He/She is nice".

Based on the gender of name, you need to pick between He and She.

You also don't cover the case where one parameter modifies the form of another parameter. For example:

"I like $NAME, who is $ADJECTIVE."

where

$ADJECTIVE is a parameter that is replaced with a stringtable entry that, depending on the gender of what's passed for $NAME can be either:

"beautiful" (for female $NAME) or "handsome" (for male $NAME)

Can you expand your suggestion to cover those possibilities?

[Blade Runner]

1. case:

"I like $NAME. He/She is nice".

I think we have to write it like:
"I like $NAME(G). $IT[G] is nice."
If the system find a pair of normal brackets () it will know it is a "transmitter" so after the name in the database there is a sign:
$NAME1 = Fiona (F)
$NAME2 = Desmond (M)
.
.
and when the system find a square bracket pair [] it will know it is a "receiver", so the transmitter will change the receiver form:
$IT [F] = she
$IT [M] = he


2. case:

"I like $NAME(G), who is $ADJECTIVE[G]."

It will work the same way:

$NAME1 = Fiona (F)
$NAME2 = Desmond (M)
.
.
and then
$ADJECTIVE [F] = beautiful
$ADJECTIVE [M] = handsome

I know this system will not cover every possibilty (ie. canot work with 2 different transmitter and receiver for 1 word), but i hope it is flexible enough to be usefull.

[Geoff the Medio]

1. case:

"I like $NAME. He/She is nice".

I think we have to write it like:
"I like $NAME(G). $IT[G] is nice."

You've added an additional parameter to the string beyond what was supplied in the original example, which is not acceptable. The number of parameters in a string (things with $'s that are replaced with other substituted strings) will not be changable by the translator. This particular example string would have only a single parameter ($NAME), and the information necessary for the string to change in response to that parameter has to be contained fully in this string itself. You can't use another parameter called $IT to get the correct pronoun... you have to have a way to pick from options within this string itself.

2. case:
"I like $NAME(G), who is $ADJECTIVE[G]."

It will work the same way:

$NAME1 = Fiona (F)
$NAME2 = Desmond (M)
.
.
and then
$ADJECTIVE [F] = beautiful
$ADJECTIVE [M] = handsome

In this case, the second parameter is already in the string, so you don't have the above problem.

But I'm a bit confused by the choice of notation... What is the purpose of the symbol G in the string? Why not do something like:

"I like $NAME, who is $ADJECTIVE[$NAME]."

Where the form of $ADJECTIVE used depends on what is passed to $NAME, without the extra symbol?

Also, I think you'll need to rewrite your syntax for $ADJECTIVE so that there is only one line involved. It won't be possible to add extra stringtable entries for each case, as you've done. All the possible forms of $ADJECTIVE will have to be contained in one line... eg.

$ADJECTIVE
beautiful[F]; handsome[M]

I picked a semicolon to separate the options... but some other separator or way of separating or indicating which flag (M or F) applies to what could be used...

Note also that the text is on a separate line form the $ADJECTIVE heading; there's no = sign involved.

[Blade Runner]

OK. I try to put a kinda pseudo variable into the notation. Without this (or other similar) pseudo variable possibility will be difficult (impossible?) to build flexible enough string substitution system. If you like to use different syntax it is OK, what is important to give the translators an easy to use, but powerfull enough string substitution system.

[Geoff the Medio]

What you have to do is work out a syntax so that you can put the various options for pronouns into another string, without requiring a separate substitution to get the correct form. We need some way to accomplish the same thing as passing a parameter into another stringtable entry, but without using an actual other stringtable entry... It could probably be done using almost the same syntax, but all in one string:

"I like $NAME. {He[$NAME, M]}{She[$NAME, F]} is nice."

Where

[$NAME, M] checks if the string $NAME is marked with the flag M, and if so text in the {} braces is used. This is kind of awkward though... Can you suggest something better?

[Blade Runner]

Hmmm... Maybe the best solution is to combine every string from 2 parts like:
"Trolden/M,B,F"
Where Trolden is a name and M B and F are flags. So when you substitute this string into a sentence, the system only put the first part (before the slash) into it.
"I hate you $Empire dirt!" -> I hate you Trolden dirt!

And your example:

"I like $NAME. {$NAME/1,0,0?M=He:F=She} is nice."

1 and 0 are flag swithes, ? separate between the control part and the value part and : separate the cases.

[Geoff the Medio]

The "?M=He;F=She" idea seems reasonable, but I don't think we need to have multiple flags in different slots. If we need mutiple flags on one stringtable entry, we can just have multiple flags, without worrying about their order... and avoid using the same flag text to mean different things in the same string, so you'd just check for M, and nothing else would use the flag M, so you wouldn't need to specify which flag slot with the binary stuff...

So you'd do:

"I like $NAME. {$NAME?M=He;F=She} is nice."

and for $NAME, a sting like this would be passed:

"Bill(M)(S)(Q)(W)"

where S, Q and W are flags that don't matter for the above string, so aren't checked for, and are ignored.

[kess]

"I like $NAME. {$NAME?M=He;F=She} is nice."

and for $NAME, a sting like this would be passed:

"Bill(M)(S)(Q)(W)"

where S, Q and W are flags that don't matter for the above string, so aren't checked for, and are ignored.

Some questions to see if I have understood this.

There is a table of strings (one set per language), e. g. for English: "I like $NAME. {$NAME?M=He;F=She} is nice."

Question: Is the information "M" or "F" stored along with the name in another table then? Due to the wealth of grammatical/syntactical/phonological/... categories needed to be considered in different languages, this may be extremely huge and complex.

Or is the "M"/"F" information stored for each language? Then it might not be so huge and complex (especially if FO is going to be translated into non-Germanic or non-IE languages). Though how would this be/is this solved?

I'm not sure of your approach...

Question: How to put text just next to the string? If $NAME = "Bill":
"$NAMEAn" --> "BillAn" (this may be desirable in some languages)
"$NAME An" --> "Bill An" (the normal way, as above)

[Geoff the Medio]

There is a table of strings (one set per language), e. g. for English: "I like $NAME. {$NAME?M=He;F=She} is nice."

Question: Is the information "M" or "F" stored along with the name in another table then?

The M or F would be embedded in the string or stringtable entry that is passed in as the value of $NAME. So there could be another stringtable entry like this:

RULER12
Bill(M)

Where the first line is the internal code name for a string, and the second is the actual stringtable entry. Both of these appear in the stringtable file... each with the code name followed by the (translated) human readable string that the game displays.

This value of the stringable entry above would be passed, by the game code, into the string

STATEMENT
I like $NAME. {$NAME?M=He;F=She} is nice.

And the game would then render the string STATEMENT to the screen as

I like Bill. He is nice.

It would know to pick "He" because the passed string RULER12 contains the flag M, which it is set to check for.

Due to the wealth of grammatical/syntactical/phonological/... categories needed to be considered in different languages, this may be extremely huge and complex.

Or is the "M"/"F" information stored for each language? Then it might not be so huge and complex (especially if FO is going to be translated into non-Germanic or non-IE languages). Though how would this be/is this solved?

The translator can add and remove flags (like M or F) as needed due to the grammtical rules of the langauge being translated to. They do this by putting the flags and tests for the flags right into the stringtable entries they're translating.

It's not really possible to encode all of this type of information in a way that the game code itself can use to synthesize strings... this is far too complicated and there are far too many cases and the programmers aren't linguists so don't even know what all the rules for various languages could be, and certainly don't have time to implement them all. This way, the translator, who actually knows the language, can do that work.

Question: How to put text just next to the string? If $NAME = "Bill":
"$NAMEAn" --> "BillAn" (this may be desirable in some languages)
"$NAME An" --> "Bill An" (the normal way, as above)

STATEMENT
$NAME{$NAME?FLAG1=An;FLAG2= An}

ONENAME
Bill(FLAG1)

OTHERNAME
Bill(FLAG2)

If the string string ONENAME was passed into STATEMENT, the check would find FLAG1 and render the "An" without a space. If the string OTHERNAME was passed into statement, the check would find FLAG2 and render " An" with a space. (The exact syntax of this isn't nailed down obviously... there might be "" quotes around the "An" and " An" substrings or somesuch)

[kess]

Thanks! (I see now that my questions were a bit fuzzy, ...excuse my English!)

[Ablaze]

It seems to me like it would be so much easier to send each of the canned messages in XML, with elements that contain all the relevant info, like.

Code: Select all

<Message type=like_message name="Bob" sex=male />

You'll have to forgive me if I don't have the sintax excatly right, but that's the general idea.

You could even have default messages (in english I guess) in case the message wasn't defined in a particular language yet.

Code: Select all

<Message type=like_message name="Bob" sex=male>I like Bob, he is cool.</Message>

[Geoff the Medio]

Ablaze, can you explain how that would work? ie. what would a translator write, how would the game know what strings to use, how is the data stored, etc. And what do you mean by "send each of the canned messages" ?

[Ablaze]

As far as I can see, a string table based translator would have to have a fragment for "I like" in the native language, one for "is nice", one for "he" and "she" and perhaps one for "name." Then, what about formal vs nonformal and other stuff that isn’t in the English language? Sure, it could be added if you think about it in advance, but I’ll guarantee that there are intricacies that haven’t yet been considered (some of which have already been pointed out in this thread.) It seems to me like, unless a great deal of effort is spent it will never look good in another language, only in English. As unix programmers say; this sounds more like “Primary language + extensions” then “multilingual.”

The system I'm using has a set of canned messages you can send, or you can just send text in your own language. You select a message from a tree that contains the possible messages. For instance, you might select "Triad Proposals->Exchange->Friendly" and select "2000 credits" and "hyperspace drive" from the popup menu. The game would then convert this to XML:

<Message id=26 give=credits give_number=2000 get=technology get_techID=96>

It would use this XML to show you your message in your own language: “I’d like to trade 2000 credits for hyperspace drive, what do you say?”
Then you send it and it’s interpreted by the other person’s XML message parser into their language:
Ich 2000 Gutschriften für hyperspace-Antrieb, was handeln möchten Sie sagen? (poor translation provided by babblefish.)

They could then reply using the same system and there would be no choppy sentences (as long as we don’t use babblefish to translate.)

“Verweigern Sie Austauschen->Insulting” turns into <Message id=145> which you see as “Not a chance, you bloated slug.”

This would also help with AI messages, since the AI would have to have a system like this anyway.