Only occurs in non-English clients (tested with German and French). This issue refers to names generated via RulePackDef (for example <li>WordImperial(p=4)->[SylB][SylB]</li> in Core\DefInjected\RulePackDef\RulePacks_Namers_People.xml).
For example, instead of 'Galo Elanekan', the name 'Galo elanekan' is generated for a pawn (the debug inspector shows <last>elanekan</last>).
Steps to reproduce #1:
- Select German language
- Load game
- Open debug logging menu
- Select 'Names From Rulepack' under 'Text generation'
- Select NamerPersonEmpire
- See debug log entry
Steps to reproduce #2:
- Select German language
- Load game
- Open debug actions menu
- Select 'Spawn pawn' under 'Spawning'
- Select Empire_Fighter_Trooper
- Spawn a bunch of them on the map
- Check their names in the Bio tab
The actual RimWorld code let the rulepack resolver do the job but it is not sufficient because the step after the rulepack, the semantic is lost and the stock c# ToTitleCase does not make it.
Name generator capitalizes nick names but not surnames, I suppose on purpose.
Something like <li>WordImperial(p=4)->[SylB_Cap][SylB][SylB]</li>
with provided capitalized syllables in the RulePacks*.xml did not work, at least last time I checked (The strings might be lowercased somewhere).
There are at least 8 semantics (people/proper names, action and business names, art titles, generic quest titles etc. which drill down to three categories of the grammatical rules for french). The language worker can detect these with a complex callstack analysis (as I did), or else extra annotations in the translations files (postprocessed in the languageworker such as the russians did), but a proper function(s) in the codebase would be easier.
Randomly generated words in multi-word faction and locality names are also affected.
Thanks, we'll look into it.
I could fix it by providing capitalized syllables and/or words as suggested by b606. The exact changes I made can be seen here: https://github.com/Ludeon/RimWorld-de/commit/dc8fe880182a4fedddf42c6f3774edfa82ee46a0.
So it seems like this should be fixed by the individual languages. Thanks for reporting.