Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Ragnar-F

#31
For example, <Biocoded>{0_gender ? biokodierter : biokodierte : biokodiertes} {0}</Biocoded>.

It is always the standard variant (male -> biokodierter). I assume that when comparing the words with the gender lists in Core/WordInfo/Gender/, the full name of the item is always used, e.g. 'Uranium gladius (normal 98%)', which is not available in the lists as such.

It would be nice if '0_gender' or any other placeholder would only refer to the name without suffix or prefix (e.g. Gladius).
#32
I would recommend to check all instances with '.Translate().ToLower()' in the code. This will cause words whose specific letters are intentionally or linguistically uppercase to always be lowercase. For example 'Reduzierte Arbeitsgeschwindigkeit: Im freien' (Work speed penalty: Outdoors), where freien needs to be Freien.

One way of doing this would be to manually uncapitalize all affected texts, remove .ToLower() and use .CapitalizeFirst() where necessary.

As far as I know, the affected texts are: On, Off, Outdoors, BadTemperature, NoPower, Infinite, Day, UntendedInjury, NoneCapable, Quality, DisabledLower, ContentNotInstalled
#33
When receiving the quest Endgame_RoyalAscent, the following error message appears (shortened to the essential):

1    root → The shuttle sent to drop off [lodgersLabelSingOrPluralDef] has been destroyed. [failLetterEndingCommon]
       lodgersLabelSingOrPluralDef → UNRESOLVABLE
2      failLetterEndingCommon → You have failed the quest '[resolvedQuestName]'.\n\nYour relations with [asker_faction_name] have decreased by [goodwillPenalty].
3        resolvedQuestName → Royal Ascendance
3        asker_faction_name → <color=#00BFFFFF>Das Gefallene Land</color>
3        goodwillPenalty → 5
     root → UNRESOLVABLE

#34
The following element in Royalty\DefInjected\QuestScriptDef\Script_EndGame_RoyalAscent.xml:


  • <EndGame_RoyalAscent.root.nodes.askerDestroyed.node.nodes.Letter.text.slateRef>{SUBJECT_definite}, für {SUBJECT_gender ? dessen : deren} Schutz du eigentlich zuständig warst, ist gestorben. [failLetterEndingCommon]</EndGame_RoyalAscent.root.nodes.askerDestroyed.node.nodes.Letter.text.slateRef>

Generates the following text:


  • Mozis, für Dessen Schutz du eigentlich zuständig warst, ist gestorben. Die Quest 'Königlicher Gast' ist fehlgeschlagen.

    Deine Beziehung zur Fraktion 'Das Gefallene Land' hat sich um 5 Rufpunkte verschlechtert.

As you can see, the first letter is upper case, but it should be lower case. This issue also exists for other similar elements such as Hospitality_Util_Worker.root.nodes.lodgersDestroyed.node.nodes.Letter.text.slateRef.
#35
Translations / Re: Note on translating for Royalty
March 26, 2020, 06:34:46 AM
Indeed, WordInfo/Gender/* seems to be completely ignored for RulePackDef, TaleDef and possibly other similar concepts. Conditions like WEAPON_gender==Female or WEAPON_projectile_gender==Male do not work. This alone would already improve the quality of the sentences significantly.

The other suggestions of b606 are also a nice-to-have.
#36
Since 1.1.2584 rev912 also for the following:

Royalty/DefInjected/QuestScriptDef/Script_BuildMonument_Worker.xml
Element: BuildMonumentWorker.root.nodes.IsTrue-2.elseNode.elseNode.nodes.IsNull.elseNode.node.nodes.Delay.expiryInfoPartTip.slateRef

Royalty/DefInjected/QuestScriptDef/Script_ChangeRoyalHeir.xml
Element: ChangeRoyalHeir.root.nodes.monumentMarkerMonumentCompleted.node.nodes.Delay.expiryInfoPartTip.slateRef

Royalty/DefInjected/QuestScriptDef/Script_EndGame_RoyalAscent.xml
Element: EndGame_RoyalAscent.root.nodes.shuttleSentUnsatisfied.node.nodes.Letter.label.slateRef

Royalty/DefInjected/QuestScriptDef/Scripts_Decree.xml
Element: Decree_BuildMonument.root.nodes.monumentMarkerMonumentCompleted.node.nodes.Delay.expiryInfoPartTip.slateRef
#37
Good catch, thanks.

Actually there were still other strange issues in the German translation, but I was able to fix them all so far (at least I hope so). Here's the link to the GitHub commit, if anyone is interested: https://github.com/Ludeon/RimWorld-de/commit/4dd792b8fdc671a1063e8bafdfc55b6a2970ba8a
#38

  • Start game
  • Switch to German (or another up-to-date language)
  • Load game / Create new colony
  • Generate quests x10 -> Hospitality_Animals
  • 3 of 10 quests throwing errors, showing 'Could Not Resolve Any Root: Quest Description'; see attachment

This seems unrelated to the translation itself, as other languages have the same issue. Other quest types are also affected, not just Hospitality_Animals. The number of erroneous quests varies for every 10 quests. May be related to https://ludeon.com/forums/index.php?topic=51185.0
#39
Thanks for considering this.

Could you please also move the thread https://ludeon.com/forums/index.php?topic=50563.0 into this subforum? I think it's the more appropriate place for this.
#40
This refers to the quest 'ThreatReward_MechPods_MiscReward', more specifically to its quest description.

When RimWorld pluralizes the threat list there, it uses labelPlural, if available, only for PawnDefs like centipede or lancer, because labelPlural only works with PawnDefs. It would be nice if we could also specify labelPlural for ThingDefs like auto charge turret or auto mortar to ensure correct translation.

For example, if I add the element '<Turret_AutoChargeBlaster.labelPlural>Auto-Energie-Turm</Turret_AutoChargeBlaster.labelPlural>' into Buildings_Mech_Turrets.xml I get the error message Field labelPlural does not exist in type Verse.ThingDef via TranslationReport.txt.

The German LanguageWorker offers only rudimentary functionality in terms of automatic pluralization, and will probably remain so, since pluralization in the German language is very variable and therefore complicated to code.
#41
Bugs / Re: [1.1.2563]translation can't work
March 06, 2020, 06:35:57 AM
In fact, this seems to affect all elements with tags ending with '.slateRef'. In the game, the element's content is always displayed in English, even if it has been translated.
#42
Translations / Re: word separation possibilities
March 02, 2020, 03:55:01 PM
This would also be a good alternative, although I believe that the other methods, especially the first one, are more flexible and cause less work.
#43
Currently, as far as I know, there are only two ways to separate a long label consisting of several words: space and \n.

In English, a label consisting of several words is separated by spaces, whereas in German (or possibly other languages) the words are usually directly concatenated. For example "tool cabinet" vs. "Werkzeugschrank". While the English label fits nicely in a Misc tab's box, the German label is erroneously separated between "Werkzeugschr" and "ank". The correct separation would be "Werkzeug" and "schrank". Currently, our translators are trying to separate such words with spaces where reasonable. This may be sufficient for such boxes, but in other places, such as headlines in item descriptions, these labels simply look crappy and wrong.

\n is out anyway, since it would make headlines mentioned above multiline.

It would be nice if there could be other ways to separate labels. For example there are the following:

  • Soft hyphen (&shy;). In general, it would make sense to allow all HTML entities if possible; some seem to work already, like &lt;, others produce an XML error. See Wikipedia page.
  • Zero-width space. See Wikipedia page.
  • <wbr>. See Wikipedia page.