Bug #1893
openruledit and ruleup output has issues with _()
0%
Description
Seen in S3_2 & S3_3.
When ruledit and ruleup write their output, in secfile_save() calling entry_to_file(), string.gt_marking is lost (always FALSE) when col_entry_name is "helptext".
In units.ruleset, string.gt_marking is lost (always FALSE) within flags ={...} and class_flags={...} , both "name" and "helptxt".
Looks like it only gets preserved for top level "name=..." and "summary=...".
Files
Updated by Dean Brown 23 days ago
- Subject changed from ruledit and ruleup output lose some _() to ruledit and ruleup output has issues with _()
Digging into this - it's weird. The struct entry with the gt_marking field is only used when writing a secfile. All () are lost when a ruleset is read in. But for some reason when a ruleset is written out, there's code that sets the gt_marking to TRUE for all struct name_translation names regardless of whether the name had a _() in the input ruleset. Also does the same for the [about] summary="..." in game.ruleset, again regardless of whether it had a _() in the input ruleset. So if I have a custom ruleset with a new unit with an untranslated name ( name="foo", no _() ), ruledit will output that as if it were a name with a translation ( name=("foo") ). Seems wrong - I think the output should either have no _() at all, or put them in for everything in the input ruleset with a _(), which would require a bunch of new coding.
The gt_marking is also used by sg_save_scenario() in savegame3.c when saving scenarios - gets applied to "scenario.name", "scenario.authors" and "scenario.description". That seems legit.
I edited the Subject to be more accurate/general.
Updated by Marko Lindqvist 23 days ago
The marking should be put to all strings that can be translated (i.e. where the freeciv engine supports translation), regardless if it was properly set in the input ruleset or not. Note that those markings are only used when collecting strings for the translators to translate.
Updated by Dean Brown 21 days ago
OK, that makes sense. In that case, seems like _() should be added for more things - for the helptext=, for the flags= and class_flags= in units.ruleset, and maybe some more things. Not hard to do.
Updated by Dean Brown 13 days ago
- File 1893_S3_2.patch 1893_S3_2.patch added
- File 1893_Main.patch 1893_Main.patch added
- File 1893_S3_3.patch 1893_S3_3.patch added
More of them than I expected -
actions.ruleset ui_name_*
cities.ruleset short_name
game.ruleset positive_label & negative_label
game.ruleset first_msg & cons_msg
game.ruleset "teams.names"
governments.ruleset ruler_male_title & ruler_female_title
techs.ruleset bonus_message
techs.ruleset control.flags "name" & "helptxt"
terrain.ruleset flags = { "name", "helptxt" ... } & extra_flags = { "name", "helptxt" ... }
terrain.ruleset ui_name_base_*
units.ruleset flags = { "name", "helptxt" ... } & class_flags = { "name", "helptxt" ... }
units.ruleset veteran_names
all helptext =
Had to add another wrapper #define for secfile_insert_str_vec_full() and rewrite secfile_insert_str_vec_full(). That meant changing utility/registry_ini.c/h so there is a problem with #1903, not a code conflict but line numbers don't match so patch won't apply. #1903 needs to be marked blocking #1893 - #1903 patches need to be done first.
Updated by Marko Lindqvist 10 days ago
Dean Brown wrote in #note-4:
#1903 needs to be marked blocking #1893 - #1903 patches need to be done first.
Ok, though personally I would arrange them the other way around - to do bugfix going to all branches first, and improvement going to yet-undecided branches second, so the bugfix patch would not need to be so different between different branches.
Updated by Marko Lindqvist 10 days ago
- Blocked by Feature #1903: improve format of output from ruledit/ruleup added