Now, "bled to death" phrase can be easily transaled, of course, but some languages do distinguish between gender of subject in verb and it can result in two different messages required.
Gennerally, Gettext is ideal mostly just for software with static text that has always same context (menus, labels, buttons ...)
Masculine/feminine is handled by providing separate strings for sentences, containing such.
Plurality is handled natively by gettext, and it knows which languages require additional forms (like, in russian there are 3 forms for counted nouns (1 singular and 2 plural), while 2 in english. Gettext knows about that and handles that natively.)
It takes some good designing for the strings, but definitely works for dynamically generated stuff. You just should provide complete sentence to gettext to make it work properly in some cases.
I don't see this as working. Changes in meaning by token-{term/word/phrase} substitution is extended beyond only gender, and using multiple sentences is possible only with embedded conditional logic, because without a higher-level abstraction capable of detecting syntax issues, there is no way to choose and display the correct basic sentence format.
DF can't even do token recognition substitution currently to my understanding, let alone token-lookup substitution and subexpression handling.
Let's take this message:
You pinch Elf 1's head with your left hand!In DF, it handles messages by using a simple token-order substitution on embedded strings (or it did in the 2D version at least). For example:
"%s %s %s' %s with %s %s!", 1.Name, 1.Action, 2.Name, 2.Part, 1.Possessive, 1.Partbut this is easily changed to recognition substitution form:
"%1% %2% %3%' %4% with %5% %6%!" % 1.Name % 1.Action % 2.Name % 2.Part % 1.Possessive % 1.PartText handling using this method is incapable of supporting multiple languages. The format string is not exported. But even if it were, the parameter string references are still unchangeable. Additional contextual information is unavailable. If the language must know the elf's gender, that information is unavailable.
DF could handle messages like this, using more expressive strings and token lookup:
message EN_ATTACK := "[1.Name] [1.Action] [2.Name]' [2.Part] with [1.Possessive] [1.Part]!"It will work for some languages. But likely only for very simple sentences. What if
2.Part ('head') works in this sentence, but in another, it interprets as 'orange?' It is also limited in available contextual information; e.g.,
2.Gender might be recognized, but
1.AttackForce is not.
I guess the next logical step is adding subexpressions:
message EN_ATTACK := {!2.Part=head?EN_ATTACK2:EN_ATTACK3}
message EN_ATTACK2 := "[1.Name] [1.Action] [2.Name]' [2.Part] with [1.Possessive] [1.Part]!"
message EN_ATTACK3 := "[1.Name] [1.Action] [2.Gender] [2.Name]' [2.Part] with [1.Possessive] [1.Part]!"It's verbose, ugly, semi-complex, lots of work, and could result in dozens of alternate definitions. At least it doesn't use inline subexpressions. But it still doesn't solve the problem of missing context. And I suspect it will fall apart with syllabic languages like Kanji or Chinese (confirm someone?).
I don't really know how to solve this. I'm not sure if anyone has. And I'm not sure if DF would need to. But I would probably try to do something like the snippet below. Call it, 'Experimental half-baked automatic language-sentence composition using a conceptual format.'
I'm not sure what a 'pinch' is supposed to be...
1: PC.Attack(NPC) => 1.Hand.Pinch(2.Head) => Intermediate format generator =>
2: (Universal) "[CUNNING] [SUCCESS] [BOLD] [SATIRICAL] [EXCITING] 1 PINCH 2 IN HEAD USING LHAND" => Language (lexical) analysis module =>
3: (English) "[IPP_CUNNING_ATK] [SUBJECT] [VP_PINCH_SETUP [V_PINCH_SETUP] [[NP_OPPONENT] | [PP_LHAND]]] [[CONJ] | [PP [VP_PINCH [V_PINCH] [NP_HEAD]] [PP_LHAND] [PP_HUMOR]]] [EXCLAMATION]" => Language composition [module]
4: "Grinning mischeviously, you taunt Elf 2 with a decisive flick to the head with your left hand!" |
5: "Nimbly somersaulting over your foe, you reach out with your left hand and push Elf 2's turned head in jest!" |
6: "Feinting to your left, you dodge Elf 2's swing and place a quick tap upside his head!"
7: (English) more grammars... |
8: (German) more grammars...
Legend: IPP = introductory prepositional phrase, VP = verb phrase, V = verb, NP = noun phrase, PP = prepositional phrase, CONJ = conjunction
In short summary:
- Line 1 is the game logic hooking into an action to generate a 'common' message format.
- Line 2 is the common format; it uses inline tags as embedded markup for later grammar suggestions. It then passes this common format to a language-defined lexer responsible for generating the language syntax.
- Line 3 is one of the language syntaxes; it uses simplified grammar rules determined by the common-format tags, and additional information retrieved from the game. It then passes the language format along to generate the message itself.
- Lines 4-6 are a stunningly overoptimistic idea of what messages could now look like.
I understand if you want to slap me silly now. It's a painfully simplified process, horrendously complicated, naively hopeful, rife with logical errors, absurdly far-fetched, idealistic, and is likely full of problems that my ignorance is robbing me of the ability to see. I'm not a linguist; in fact, I rate my English ability as a 1 or 0.5 on a scale of 1 to 10. As well, Toady has probably considered all of this years ago.
...but I would appreciate insight.
I tend to find this topic interesting.
Author
Topic: Language source code (Read 1923 times)