Perl / Scripting / *nix / Database / Sysadmin work

[Skizac]

As I stated elsewhere, I'm very interested in coding for the game itself, but my true skills currently lie with Perl, shell scripting, *nix, databases, and all kinds of sysadmin work.

So, if anybody has work for Wesnoth that falls in those areas, send it over to me.

[Darth Fool]

Well, one thing that I would love to see is a perl script that parses, optionally recursively, all the cfg files in a directory and constructs a map of how WML is used. By this I mean mapping out what the various [tags] are, what values things can be set to, etc. The purpose of this would be eventually to make an automated check of what new WML values have been added and make it easier to document what all the WML does. Just a thought. It would be a great way to learn the WML syntax as well.

[Skizac]

Well, one thing that I would love to see is a perl script that parses, optionally recursively, all the cfg files in a directory and constructs a map of how WML is used. By this I mean mapping out what the various [tags] are, what values things can be set to, etc. The purpose of this would be eventually to make an automated check of what new WML values have been added and make it easier to document what all the WML does. Just a thought. It would be a great way to learn the WML syntax as well.

Ok, this sounds like it could be a relatively straight-forward project. However, I'm not exactly sure what you're asking for. What would be the nature of the "map"? What would the output of the program be? Is my understanding correct that this would be a two-phase project?

1) Build a map of WML code from cfg files.
2) Make a (syntax?, semantics?) check of the WML values in the mapping.

[ivanovic]

I think the idea behind this is making a reference of all possible WML. This would include the semantics inside the tags.
1) Get all possible commands.
2) Find out the correct/allowed semantics for the commands found before.

Something like this would be a great help to get a nice reference since only very little editing afterwards would be needed. At least if we actually are using the tags and semantics in the "mainfiles".

[Skizac]

I think the idea behind this is making a reference of all possible WML. This would include the semantics inside the tags.
1) Get all possible commands.
2) Find out the correct/allowed semantics for the commands found before.

Something like this would be a great help to get a nice reference since only very little editing afterwards would be needed. At least if we actually are using the tags and semantics in the "mainfiles".

Ah, I get it now. Sort of automaticly-generated documentation. It's on my todo list.

[Boucman]

if you go in the utils/ directory, you will find an already existing WML parser... that would be a good starting point...

[Viliam]

Another idea...

The first tool could check which WML tags can include which WML tags and attributes, and could generate a description file (something like DTD files that describe what can appear in XML files). That description file could also be a WML file and could be like this:

Code: Select all

[tag]
  name="unit"
  [attribute]
    name="id"
    type=string
  [/attribute]
  [attribute]
    name="name"
    type=string
    localized=yes
  [/attribute]
  [subtag]
    name="attack"
  [/subtag]
[/tag]

This means that tag "[unit]" can contain tags "[attack]" and attributes "id" and "name". Attribute "name" can be localized.

Now, another tool would check user-made files (user campaigns, etc), first check whether they are correct WML files, then validate them against the description file. The error report from such tool could be much better than the feedback provided by Wesnoth program; and also faster.

[ott]

The tagfind script (in utils/) has been in the repository since July 2005. It's not comprehensive, but it's a start, and was very useful in generating the WML index at the wiki.

[Skizac]

Another idea...

The first tool could check which WML tags can include which WML tags and attributes, and could generate a description file (something like DTD files that describe what can appear in XML files). That description file could also be a WML file and could be like this:

Code: Select all

[tag]
  name="unit"
  [attribute]
    name="id"
    type=string
  [/attribute]
  [attribute]
    name="name"
    type=string
    localized=yes
  [/attribute]
  [subtag]
    name="attack"
  [/subtag]
[/tag]

This means that tag "[unit]" can contain tags "[attack]" and attributes "id" and "name". Attribute "name" can be localized.

What would "localized" mean in this context?

[torangan]

Translated.

[scott]

Localized means the key has the format:
keyname / equals / underscore / quoted text
name= _ "Joe"

This format marks the quoted text as translatable by "gettext", a program that manages translations. Gettext will then collect the string and add it to the list of strings it shows translators for them to translate. Later on, gettext localizes the string by substituting the translated text into every instance of the quoted text, thus showing the information in the player's local language.

(Didn't know how long of an answer you needed)

[Viliam]

Localized means the key has the format:
keyname / equals / underscore / quoted text
name= _ "Joe"

It is a bit more difficult, because the value can be an expression, where only a part of expression is translatable. For example:

description= _ "Max HP bonus +" {HP_ADVANCE}
(from "amla.cfg")

text="<img>src=misc/logo.png align=middle box=no</img>" + _"
Battle for Wesnoth is a turn-based fantasy strategy game..."
(from "help.cfg")

If a part of expression is localized, mark the whole attribute as localizable.

Print error when user localizes a non-localizable attribute. Print warning when user does not localize a localizable attribute (there should be a switch to turn off these warnings).

[Skizac]

Ok, I've got a somewhat working version coded up. However, the utils/wml.pm module doesn't handle preprocessor directives very well, and chokes on several wml files. Is there a way to run all of the wml files through the preprocessor so that I only have to deal with preprocessed wml?