Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[psyn]

I think that falls under what I wrote earlier.

I guess the next logical step is adding subexpressions:

Code: [Select]

message EN_ATTACK        := {2.Gender = male ? EN_ATTACK_MALE : EN_ATTACK_FEMALE}
message EN_ATTACK_MALE   := "[1.Name] [1.Action] [2.Name]' [2.Part] with [1.Possessive] [1.Part]!"
message EN_ATTACK_FEMALE := Female-specific format.

could also be done as:

Code: [Select]

message EN_ATTACK := {2.Gender = male}   Male-specific format.
message EN_ATTACK += {2.Gender = female} Female-specific format....syntax is a fairly irrelevant issue at this stage.

Here is how I described the method:

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?).

As you say, it will have lots of duplication going on. Yeah, it probably will suffice for the most common languages, with enough effort. But to take your example, if the [BLUNT_ATTACK] conditional is not defined and a language requires it, that technique will produce incorrect results.

I only know two written languages, and only one of them moderately well, so I'm finding trouble estimating very well how often or when such a localization method would err because of information deficiency.

Also -- now that I properly understand what you mean -- generating sentences for every possible combination is insane! Assume 50 actions, 300 parts (twice), 10 possessives... Yeah... OK... 45,000,000 combinations... times a dozen languages... 540,000,000... assuming an average of 40 characters/message (80 bytes)... 40 GIGABYTES of raw text... all for the ONE simplest message!