WesPo 2.0

Discuss and coordinate development of mainline and user-made content translations.

Moderator: Forum Moderators

User avatar
Nobun
Code Contributor
Posts: 129
Joined: May 4th, 2009, 9:28 pm
Location: Italy

WesPo 2.0

Post by Nobun »

I don't now if "User's Forum" is the right place...

However, after several years, I created a new version of Wespo (wespo 2.0 RC1).

Image

Wespo is an alternate, unofficial, tool that allows users to obtain easily a blank .po file (saved as skele.po). Unlike WesCamp it is used on local drive and create the .po immediately (ie: you can obtain a .po file even if you don't upload your add-on on main server). I added a lot of improvements on 2.0 RC1:

* textdomains are now recognized, and only the strings on the add-on textdomain will be exported on skele.po
* A complete new sourcecode: now WesPo will create, like WesCamp, comments about where the string was. Syntax is slightly different from wescamp:

[tag]: param = info ; //like WesCamp
{MACRO ...} ; //when a string is placed on a macro call (wespo doesn't expand macros)
(in macro definition: MACRO) ; //when a string is in the mainbody of a #define MACRO

parametrized tags: unit, side, message and chat. All other tags will return only the tagname
lua: lua code (both in [lua] tag or in a .lua file) will be marked as [lua]:

* Chance to customly override the default comment output with a string, using a special comment in WML, before the string itself:
# wespo: <custom comment>
(on lua: -- # wespo: <custom comment>)

* Unluckly the version has two bugs described in README.html (this why it is published as a Release Candidate): I am not even sure that they are truely bugs or they happen only on my PC: in any cases I described them and explained how to manage those situations

download: wespo.sourceforge.net

Hope this helps :)
User avatar
SkyOne
Posts: 1310
Joined: January 3rd, 2009, 7:23 pm

Re: WesPo 2.0

Post by SkyOne »

Hello Nobun,

This is a great attempt. Thank you so much. :)
Releasing the Mac version is not under your plan, is it?
Fate of a Princess/feedback thread: "What is in own heart that is the most important, not who you are."
Drake Campaign: Brave Wings/feedback thread, Naga Campaign: Return of the Monster, Saurian Campaign: Across the Ocean
Northern Forces - now on 1.12 server
User avatar
Nobun
Code Contributor
Posts: 129
Joined: May 4th, 2009, 9:28 pm
Location: Italy

Re: WesPo 2.0

Post by Nobun »

Unluckly I cannot build a binary for Mac. Cross compiling for mac is even harder than cross compiling for Windows, and I have no direct experience on Mac...

However, since the source code is entirely written with qt libraries, it can be builded also on Mac. Follow the "Linux" link, download sources and follow README instructions.

Let me know if the program works well also in Mac :)
User avatar
James_The_Invisible
Posts: 534
Joined: October 28th, 2012, 1:58 pm
Location: Somewhere in the Northlands, fighting dark forces
Contact:

Re: WesPo 2.0

Post by James_The_Invisible »

You only need to select folder with your add-on and click one button to get po file for your campaign? It is magic :D . Really nice.
Unfortunately when I tried it on a campaign of mine, I received error: bad macro call (verify your graphs!). The content of the mentioned line is:

Code: Select all

description= _ "TODO."+{SPECIAL_NOTES}+_"SPECIAL_NOTE^Mystics are well-attuned to their magical natures and are highly resistant to non-physical damage."+{SPECIAL_NOTES_MAGICAL}+{SPECIAL_NOTES_TELEPORT}
which is valid WML, there is nothing wrong with this code. Macros do not have to take any parameters (if that is the cause of the error). (And I am not sure what you mean with the graphs ...)
User avatar
Nobun
Code Contributor
Posts: 129
Joined: May 4th, 2009, 9:28 pm
Location: Italy

Re: WesPo 2.0

Post by Nobun »

Thank a lot for bug report. Seeing your WML code I can confirm that this is a error I made on my program. I will fix it as soon as possible.

I think I understood why my application returns an error in this case, even if it is a WML valid code
Spoiler:
I did a lot of tests, and every bug report is really appreciated :) Now I will work on fixing it :) Thank a lot for bug reporting :)
User avatar
Nobun
Code Contributor
Posts: 129
Joined: May 4th, 2009, 9:28 pm
Location: Italy

Re: WesPo 2.0

Post by Nobun »

Sorry for double posting but I have to announce I fixed the bug reported by Jack the invisible.

Moreover, I finally discovered why the two known bugs on 2.0 RC1 happened. So I fixed them too.

Now I released a new 2.1 version that is a bugfix of the previous 2.0 RC1 published yesterday.

2.1 version should be a stable version and should be bug free.

Please test it and report me if you discover any bug :)
User avatar
James_The_Invisible
Posts: 534
Joined: October 28th, 2012, 1:58 pm
Location: Somewhere in the Northlands, fighting dark forces
Contact:

Re: WesPo 2.0

Post by James_The_Invisible »

This fixed the problem. Thank you. However, notes for most of tags (which I have in the campaign) lack any additional info, the whole content is just [tag]:. Only for [message]s it contains speaker= ... . Is it supposed to be this way?
(And by the way, who is that Jack who you mentioned? :lol: )
User avatar
Nobun
Code Contributor
Posts: 129
Joined: May 4th, 2009, 9:28 pm
Location: Italy

Re: WesPo 2.0

Post by Nobun »

lol... I thought I wrote badly your name :lol:

However... this is the normal behaviour of wespo. Wespo transfer param infos that can help TRANSLATORS to understand better the context of a sentence, and how to translate it.

By default wespo outputs those additional infos:

tag [message] and tag [chat]:
will be reported speaker or role if specified. If none specified wespo will return speaker = message (default value for message) or speaker = WML (default value for chat)
This, infact, is an important information for a translator: some languages, for example distinguish male and female forms (like my own native language: italian) and so on. Moreover, knowing the speaker id allows translator to understand better who is speaking, and to figure better the global context of the message

tag [side] and tag [unit]:
will be reported: type, id and gender (if specified). In this case wespo will report only param(s) that are really used on WML tag. If none of those params are used, wespo simply returns the tagname.
Type of unit/side can be useful in some context (it is a spearman, an archer?) for a translator
Id of unit/side is an important info for a translator. Like message.speaker, it allows to understand about what character we are speaking about.

tag [objective]:
condition = win/lose
this is the last very helpful information I found for a translator. Since objective text could be obvious to translate, however it is important to show if we are speaking about winning or losing condition

-------------

a part of them, I found no other informations really useful for a translator, this is why other tags doesn't explain anything else a part tagname itself (with the exception of [part] tag that is written as [story]: [part]: it is more clearer for a translator becouse it explicitly says that we are in a [story] context)

Those are all infos that I found really useful for a tanslator, but I am open to suggestions if other informations can be useful for a translator.

With an important exception. For tag [lua]: (or lua code) it is not possible to explicit anything by default (wespo is not a lua parser). In that case, the best thing to do is to use the # wespo: <custom information> command in WML/Lua to customize wespo information output for a particular string
User avatar
James_The_Invisible
Posts: 534
Joined: October 28th, 2012, 1:58 pm
Location: Somewhere in the Northlands, fighting dark forces
Contact:

Re: WesPo 2.0

Post by James_The_Invisible »

Well, I am especially missing ids for descriptions of abilities/weapon specials. You are probably right that other tags do not really need additional comments. (I am just used to see them in po files from WesCamp).
A small thing that I have noticed: in Poedit in properties of the catalog, field Name and version of the project is empty. You are adding the relevant key Project-Id-Version into the generated file but it has no value. It should be in this form: Name_of_addon_Version_of_Wesnoth (the stable one, 1.x, currently 1.12). You can get the name of add-on from the name of its top folder.
User avatar
Nobun
Code Contributor
Posts: 129
Joined: May 4th, 2009, 9:28 pm
Location: Italy

Re: WesPo 2.0

Post by Nobun »

hmm... Do you mean that id values can be helpful for translators? In that case I see how to expand internal rules.
field Name and version of the project is empty. You are adding the relevant key Project-Id-Version into the generated file but it has no value. It should be in this form: Name_of_addon_Version_of_Wesnoth (the stable one, 1.x, currently 1.12). You can get the name of add-on from the name of its top folder.
Well I have to admit I didn't know what to do, if trying to fill head parameters or not. I decided to DON'T fill parameters (except for translation team, that can be edited) mainly because those infos can be easily handly edited.

I didn't understand about the correct value (if it is only 1.12 or 1.12-campaign name or so on)... however it is not so easy to set it up in a solid way. There could be situations where the solution is not so obvious (the first example that comes in my mind: wesnoth on windows, installing user data in game directory and not in HOME, installing game in a custom directory). Moreover I would like to avoid to add something else to GUI (my intention is: wespo should be user-friendly... as much as possible). So if it isn't an important missing, I would choose to don't change this part of the program, since that field can be easily change editing the skele.po created by wespo.

what do you think about it?
User avatar
James_The_Invisible
Posts: 534
Joined: October 28th, 2012, 1:58 pm
Location: Somewhere in the Northlands, fighting dark forces
Contact:

Re: WesPo 2.0

Post by James_The_Invisible »

Nobun wrote:hmm... Do you mean that id values can be helpful for translators?
It usually matches the name of that ability/special, so I think yes.
I didn't understand about the correct value ...
An example (for my campaign): For_Power-1.12.
1.12 is used for campaigns for Wesnoth 1.11 a 1.12 (it is actually not out yet but 1.11 is beta version for it). Well, but if the add-on is for 1.10 you should use 1.10. It makes the things a bit complicated ...

Yes, I too think that adding more elements into GUI would not be good. I like its current simplicity. But you do not have to add next field for it ...
I have not studied source code of your program but the entered path should be stored in a variable, right? So you could break it into parts where the parts are separated by / or \ and take the last one.
But just like I said, this is a very small thing. You do not have to worry about it if you do not want. It would be nice but I do not find it necessary.

Sorry that I was/am not clear. My english is not so good.
User avatar
Nobun
Code Contributor
Posts: 129
Joined: May 4th, 2009, 9:28 pm
Location: Italy

Re: WesPo 2.0

Post by Nobun »

hmm... Do you mean that id values can be helpful for translators?
It usually matches the name of that ability/special, so I think yes.
Well... I think it is a good idea to add a global "id" rule, than (= always display id value of a tag, if present). In this way we can avoid to forget some other important tags where id can be helpful. This will mean that id will be added also when it is not important (like in [campaign] tag) but I think this is the best approach.

Before adding this rule and releasing another update, are there other important informations I need to add, in your opinion?
I didn't understand about the correct value ...
An example (for my campaign): For_Power-1.12.
Now I understood, thank :)
I have not studied source code of your program but the entered path should be stored in a variable, right? So you could break it into parts where the parts are separated by / or \ and take the last one.
Lol... I don't think that my source code is enough good to be studied :P
however I confirm that the entered path is stored and managed in two different ways (one is: obtaining fileref -> add-ons/ADDON_NAME/filepath). But the problem I am thinking about is not related to the add-on name (like you mentioned, it could be enough to capture the path entered) but the wesnoth version for that add-on.
In most case, wesnoth version can be found in path too (I am thinking about linux standard paths), but in other cases not. For example: if a user installed wesnoth in a custom path and userdata in a custom path... we cannot be 100% sure to retrieve the correct information about wesnoth version. This is why I doubt I can find a solid way to auto-complete Project-id-version and perhaps the better solution is to left it blank
User avatar
James_The_Invisible
Posts: 534
Joined: October 28th, 2012, 1:58 pm
Location: Somewhere in the Northlands, fighting dark forces
Contact:

Re: WesPo 2.0

Post by James_The_Invisible »

Nobun wrote:are there other important informations I need to add, in your opinion?
I cannot think of anything that I am really missing now. I will tell you if I find something.
Lol... I don't think that my source code is enough good to be studied :P
I meant just to know how it internally works :D .
But the problem I am thinking about is not related to the add-on name ... but the wesnoth version for that add-on.
Yes, that might be complicated. Until Wesnoth 1.12 comes out, I think that expecting 1.10 would not be bad (most translators translate for stable version, I think; 1.10.7 is the latest stable version at the moment). But if you want to leave that field empty, I am fine with it :) .
User avatar
Nobun
Code Contributor
Posts: 129
Joined: May 4th, 2009, 9:28 pm
Location: Italy

Re: WesPo 2.0

Post by Nobun »

Hoping that you are running wespo on linux...
...I submit you a patch for wespo that apply the global rule id...

assuming you copied wmlReader.patch in your "src" directory...

open a console, reach the "src" directory and apply patch to sources with:

patch < wmlReader.patch

after that you can rebuild wespo as usual. In that way (if you can recompile wespo) you can have a preview of the modify and see better if other important WML informations are missing.

Thank for contribute :D

p.s. I am still thinking about the "Project-id" thing ... ;)
Attachments
wmlReader.patch
(620 Bytes) Downloaded 539 times
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: WesPo 2.0

Post by Dugi »

Does it also have a feature to update existing translations so that the translation remains unchanged if the original string changes a little bit (using a diff of the campaign's files or something)? It would beautifully allow campaign authors to improve the prose without having concerns about ruining all translations in the process.
Post Reply