Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Schema validation does not see the _ at the start of t_strings #4537

Open
stevecotton opened this issue Nov 2, 2019 · 2 comments

Comments

@stevecotton
Copy link
Contributor

@stevecotton stevecotton commented Nov 2, 2019

Game and System Information

Linux, current git master at 1a67d53
Running the validator with build/debug/wesnoth --userconfig-dir ~/.config/wesnoth1.15/ --data-dir $PWD --validate data/_main.cfg --preprocess-defines=TEST,SCHEMA_SHOULD_SKIP_THIS

Describe the bug

The engine for schema validation strips the underscore from translatable strings before checking the value with the schema, which means that the schema can't enforce translatability of strings.

The schema declares that t_strings should optionally start with an underscore; this bug is hidden because the schema says the underscore is only optional:

[type]
name=t_string
value="_?.*"
[/type]

I want to change that regexp is to only allowing (empty without underscore) or (value starting with underscore), value="()|(_.*)". However, doing that will return a huge list of errors, finishing with

error validation: Invalid value 'Teal' in key 'name=' in tag [color_range]
at core/team-colors.cfg:287
    included from game_config.cfg:123
    included from data/_main.cfg:102

even though there is an underscore on that line (and the other lines that are complained about):

name= _ "Teal"

@CelticMinstrel

This comment has been minimized.

Copy link
Member

@CelticMinstrel CelticMinstrel commented Nov 3, 2019

This is probably not caused by anything in the schema; it's likely due to the WML parser converting the raw WML into actual typed data by the time the schema sees it. I think the idea of trying to match translatable strings via regex is probably flawed to begin with, given that. But I'm not sure if there's really a better way, other than maybe accepting a translatable=yes key in the [type] tag…

Another thing to note is that not all strings that could be translatable are marked as such. For example, I believe most of the test scenarios do not mark their strings translatable.

@Wedge009 Wedge009 added the Bug label Nov 3, 2019
@soliton-

This comment has been minimized.

Copy link
Member

@soliton- soliton- commented Nov 5, 2019

I think it'd be fine for t_string to be a type just for documentation purposes. As @CelticMinstrel says we don't want to enforce marking every string translatable just because the WML key supports it.

I'd change the regex to: .*

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.