Perl / Scripting / *nix / Database / Sysadmin work
Moderator: Forum Moderators
Perl / Scripting / *nix / Database / Sysadmin work
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.
So, if anybody has work for Wesnoth that falls in those areas, send it over to me.
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
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.
"you can already do that with WML"
Fight Creeeping Biggerism!
http://www.wesnoth.org/forum/viewtopic. ... 760#131760
http://www.wesnoth.org/forum/viewtopic. ... 1358#11358
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?Darth Fool wrote: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.
1) Build a map of WML code from cfg files.
2) Make a (syntax?, semantics?) check of the WML values in the mapping.
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".
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.ivanovic wrote: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".
- Viliam
- Translator
- Posts: 1341
- Joined: January 30th, 2004, 11:07 am
- Location: Bratislava, Slovakia
- Contact:
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:
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.
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]
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.
What would "localized" mean in this context?Viliam wrote: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:
This means that tag "[unit]" can contain tags "[attack]" and attributes "id" and "name". Attribute "name" can be localized.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]
Translated.
WesCamp-i18n - Translations for User Campaigns:
http://www.wesnoth.org/wiki/WesCamp
Translators for all languages required: contact me. No geek skills required!
http://www.wesnoth.org/wiki/WesCamp
Translators for all languages required: contact me. No geek skills required!
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)
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)
Hope springs eternal.
Wesnoth acronym guide.
Wesnoth acronym guide.
- Viliam
- Translator
- Posts: 1341
- Joined: January 30th, 2004, 11:07 am
- Location: Bratislava, Slovakia
- Contact:
It is a bit more difficult, because the value can be an expression, where only a part of expression is translatable. For example:scott wrote:Localized means the key has the format:
keyname / equals / underscore / quoted text
name= _ "Joe"
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).