WesPo 2.0
Moderator: Forum Moderators
Re: WesPo 2.0
Nope. Wespo create only a blank .po file, sorry 
This becouse an official tool already exists and it is msgmerge. So my program is only an alternative method to obtain the untraslated base .po file, trying to be as easy as possible
WesCamp create a blank .po file too, as far as I know. When you need to "upgrade" an already existing .po (old translation) with the new empty file, you need to merge the new empty .po and create a third .po.
So this is the steps to follow:
- first create the skele.po with wespo
- second use msgmerge. Example:
msgmerge -o new.po old.po skele.po
where old.po is the .po file with the old translation
skele.po is obliouvsly the untraslated .po created by wespo
new.po will be the new .po file created with msgmerge that will contains the new (or modified) entryes in skele.po and saves the old translations contained in old.po.
When sentences are similar but not equal to a translated one, the old translation will be marked as obsolete (becouse unactive, it will not work since it doesn't match anymore an already string to translate) but still remains in memory and the work did in the past can be reused.
msgmerge is a tool that is a part of the official gettext project (po file format is related to the gettext project). It can be easily found on your linux distro (if you are using linux).
For windows people, usually msgmerge will be installed together with a translation program. For example I can confirm that windows version of Poedit (I used in past, when I already had windows) contains a copy of msgmerge.exe
Hoping this helps
This becouse an official tool already exists and it is msgmerge. So my program is only an alternative method to obtain the untraslated base .po file, trying to be as easy as possible
WesCamp create a blank .po file too, as far as I know. When you need to "upgrade" an already existing .po (old translation) with the new empty file, you need to merge the new empty .po and create a third .po.
So this is the steps to follow:
- first create the skele.po with wespo
- second use msgmerge. Example:
msgmerge -o new.po old.po skele.po
where old.po is the .po file with the old translation
skele.po is obliouvsly the untraslated .po created by wespo
new.po will be the new .po file created with msgmerge that will contains the new (or modified) entryes in skele.po and saves the old translations contained in old.po.
When sentences are similar but not equal to a translated one, the old translation will be marked as obsolete (becouse unactive, it will not work since it doesn't match anymore an already string to translate) but still remains in memory and the work did in the past can be reused.
msgmerge is a tool that is a part of the official gettext project (po file format is related to the gettext project). It can be easily found on your linux distro (if you are using linux).
For windows people, usually msgmerge will be installed together with a translation program. For example I can confirm that windows version of Poedit (I used in past, when I already had windows) contains a copy of msgmerge.exe
Hoping this helps
Re: WesPo 2.0
Thanks for the info. I have Linux, so msgmerge will not be an issue.
Well, find&replace in multiple files will by my way here, then, using msgmerge just to add new lines.becouse unactive, it will not work since it doesn't match anymore an already string to translate
Re: WesPo 2.0
perhaps I explain badly, becouse msgmerge IS the tool... I wouldn't suggest you to use find & replace...
I try to make two examples, to be more clear:
Example1:
old sentence = "sentence 1"
old translation = "translation sentence 1"
new sentence = "sentence 1"
------------------------
In the first example, while in other part the original sentences changed somehow, this sentence existed in the old translated old.po file. In skele.po will be obliouvsly untranslated. In the new.po file created by msgmerge it will be merged as the old sentence "sentence 1" with the old translation "translation sentence 1".
So the old translation will be saved and already available
The final result in new.po will be a translated string with the old translation
------------------------
Example2:
old sentence = "I will kill"
old translation = "translation 1"
new sentence = "I will kill you"
---------------------------
In the second example there is an old.po that contained "sentence 1". But "sentence 1" doesn't anymore exists in the original add-on. At its place there is a new "sentence 1 B" . For example... in a campaign, in a first scenario, an enemy say "I will kill". But in the revised version of the campaign itself the sentence is changed in "I will kill you". So the sentence "I will kill" dosn't exist anymore in the campaign and replaced by "I will kill you".
So this is what happens:
- old.po contains a translation for "I will kill", but the sentence "I will kill" doesn't exist anymore in the add-on, so the sentence "I will kill" will never be translated in the new version
- skele.po produced by WesPo will contain an untranslated "I will kill you" and will not contain anymore "I will kill" (that it isn't anymore used in the add-on)
- new.po created by msgmerge will contain an untranslated and "active" sentence "I will kill you" but doesn't forget the unusable sentence "I will kill". It simply marks adds the old "I will kill" as an obsolete sentences (with the related translation) that should be erased becouse useless. But you can find the old sentence in the file and use it as a base to translate the active and untranslated "I will kill you" and then delete the obsolete sentence.
Hope that with an example it is more clear
I try to make two examples, to be more clear:
Example1:
old sentence = "sentence 1"
old translation = "translation sentence 1"
new sentence = "sentence 1"
------------------------
In the first example, while in other part the original sentences changed somehow, this sentence existed in the old translated old.po file. In skele.po will be obliouvsly untranslated. In the new.po file created by msgmerge it will be merged as the old sentence "sentence 1" with the old translation "translation sentence 1".
So the old translation will be saved and already available
The final result in new.po will be a translated string with the old translation
------------------------
Example2:
old sentence = "I will kill"
old translation = "translation 1"
new sentence = "I will kill you"
---------------------------
In the second example there is an old.po that contained "sentence 1". But "sentence 1" doesn't anymore exists in the original add-on. At its place there is a new "sentence 1 B" . For example... in a campaign, in a first scenario, an enemy say "I will kill". But in the revised version of the campaign itself the sentence is changed in "I will kill you". So the sentence "I will kill" dosn't exist anymore in the campaign and replaced by "I will kill you".
So this is what happens:
- old.po contains a translation for "I will kill", but the sentence "I will kill" doesn't exist anymore in the add-on, so the sentence "I will kill" will never be translated in the new version
- skele.po produced by WesPo will contain an untranslated "I will kill you" and will not contain anymore "I will kill" (that it isn't anymore used in the add-on)
- new.po created by msgmerge will contain an untranslated and "active" sentence "I will kill you" but doesn't forget the unusable sentence "I will kill". It simply marks adds the old "I will kill" as an obsolete sentences (with the related translation) that should be erased becouse useless. But you can find the old sentence in the file and use it as a base to translate the active and untranslated "I will kill you" and then delete the obsolete sentence.
Hope that with an example it is more clear
Re: WesPo 2.0
"I will kill" and "I will kill you" are actually similar enough that msgmerge will give it "translation 1", but mark it as "fuzzy". This means that the translator instantly sees it and can do a small fix on the string right away, but that the addon will not use this translation until the "fuzzy" marker has been removed by a translator.
Re: WesPo 2.0
Thank for correcting me, GunChieoc
May I ask you a thing?
Is it better that the sentences inside the untranslated po (in this case, skele.po created by wespo) are marked as fuzzy or not?
for example: when using
msgmerge -o new.po old.po skele.po
In its own startup setting wespo has "fuzzy" checkbox unselected (all sentences in skele.po are NOT marked as fuzzy), unless the "fuzzy" checkbox will be selected when creating a skele.po (all sentences in skele.po will be fuzzy, instead). What is the best setting? "fuzzy" or not?
May I ask you a thing?
Is it better that the sentences inside the untranslated po (in this case, skele.po created by wespo) are marked as fuzzy or not?
for example: when using
msgmerge -o new.po old.po skele.po
In its own startup setting wespo has "fuzzy" checkbox unselected (all sentences in skele.po are NOT marked as fuzzy), unless the "fuzzy" checkbox will be selected when creating a skele.po (all sentences in skele.po will be fuzzy, instead). What is the best setting? "fuzzy" or not?
Re: WesPo 2.0
It is better to have a fuzzy marking - you will lose the translation in-game, but it prevents you from having a wrong translation when the meaning of the source string has changed. Translators should check each case for if it needs retranslating.
-
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
Hello again. I have come across a small issue. Accidentally, I have used id attribute instead of speaker in [message] tag and in comment for the relevant string is written speaker=narrator and not id=whatever. These two attributes have the same meaning in this context, they select the speaker. I used the last released version for Windows, 2.1. (Edit: well, you can probably ignore it. I should try to apply your patch firstly. Changes in it might fix this issue.)
About updating translations, there is an alternate procedure. You just change extension of the new file to .pot (well, this step is not really necessary), open your old file in Poedit (or a similiar program), click Catalogue in menu and then Update from POT file... and find the new file.
About updating translations, there is an alternate procedure. You just change extension of the new file to .pot (well, this step is not really necessary), open your old file in Poedit (or a similiar program), click Catalogue in menu and then Update from POT file... and find the new file.
My content: For Power series
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Re: WesPo 2.0
@Gunchleoc: thank for answering
@James the invisible:
Thank for the bug report... I didn't know you could use "id" inside [message] tag with the same meaning as speaker.
This is why, even in the source-patch, the id global rule is applied only as an "else" rule (this means -> id value shown in all tags, but not [message], [chat], [objective]).
Now I will mark also this issue and I will fix it. Only a question:
when wespo find a [message] or [chat] with id=person ... is it better to show
[message]: id=someone
or
[message]: speaker=someone
?
Thank for contributing
@James the invisible:
Thank for the bug report... I didn't know you could use "id" inside [message] tag with the same meaning as speaker.
This is why, even in the source-patch, the id global rule is applied only as an "else" rule (this means -> id value shown in all tags, but not [message], [chat], [objective]).
Now I will mark also this issue and I will fix it. Only a question:
when wespo find a [message] or [chat] with id=person ... is it better to show
[message]: id=someone
or
[message]: speaker=someone
?
Thank for contributing
-
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
In my opinion, speaker=someone. I find id here somehow vague.
Wiki says that you can use either speaker attribute or StandardUnitFilter (which id is a part of of) to determine the speaker.
Wiki says that you can use either speaker attribute or StandardUnitFilter (which id is a part of of) to determine the speaker.
My content: For Power series
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Re: WesPo 2.0
Very nice point.
Becouse, thank of your remind, I see another thing to improve somehow in wespo
1) on tag [message] and [chat]: message could use not only "id" but also other standard unit filter. This means that also gender and type could be used. Those ones (gender and type) could be important infos for translator, if present (even if I figure that usually are not used on [message]). Other than id, role (already implemented), type and gender I don't see other params in standard unit filter that are really useful. On [message] "type" could be shown as "(unit) type =" to be more clear for a translator
2) on tag [side] and [unit]: I missed that "role" was in standard unit filter. So also the "role" parameter on those tags should be added
3) Missing rules:
Also other tags could be affected by this "standard unit filter".
I mean: perhaps, other than side, message and chat -> there could be other tags (that has translatable strings) that uses standard unit filter without [filter].
So... can you remind me what other tags uses "standard unit filter" without [filter]?
We must exclude however [filter] [filter_second] or similar, and conditional tags (becouse a translatable string is not directly inside a conditional tag, but it is inside a subtag, ex [message] or other).
Thank again for helping
Becouse, thank of your remind, I see another thing to improve somehow in wespo
1) on tag [message] and [chat]: message could use not only "id" but also other standard unit filter. This means that also gender and type could be used. Those ones (gender and type) could be important infos for translator, if present (even if I figure that usually are not used on [message]). Other than id, role (already implemented), type and gender I don't see other params in standard unit filter that are really useful. On [message] "type" could be shown as "(unit) type =" to be more clear for a translator
2) on tag [side] and [unit]: I missed that "role" was in standard unit filter. So also the "role" parameter on those tags should be added
3) Missing rules:
Also other tags could be affected by this "standard unit filter".
I mean: perhaps, other than side, message and chat -> there could be other tags (that has translatable strings) that uses standard unit filter without [filter].
So... can you remind me what other tags uses "standard unit filter" without [filter]?
We must exclude however [filter] [filter_second] or similar, and conditional tags (becouse a translatable string is not directly inside a conditional tag, but it is inside a subtag, ex [message] or other).
Thank again for helping
-
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
Hm, I do not know of any other (from those which could contain translatable strings).So... can you remind me what other tags uses "standard unit filter" without [filter]?
My content: For Power series
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Re: WesPo 2.0
Thanks for that informationNobun wrote:perhaps I explain badly, becouse msgmerge IS the tool...
[...]
. It's really good to know that I can make small language corrections to the dialogues after getting it translated.(and sorry for the delay, I was away)
Re: WesPo 2.0
Wespo 2.2 is released!
changelog from version 2.1:
A special thank to James the invisible for his testings and suggestions
(note: the project-id on header informations is left blank :/ ).
Test it and report any bug or other improvement needed.
Note: for those who are interested, I also uploaded an online version of source code documentation (link available at the end of wespo homepage)
changelog from version 2.1:
Spoiler:
(note: the project-id on header informations is left blank :/ ).
Test it and report any bug or other improvement needed.
Note: for those who are interested, I also uploaded an online version of source code documentation (link available at the end of wespo homepage)
-
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
Hello again, Nobun. I have come across two issues with your program. Firstly, it seems that translatable strings in macros calls are exported no matter their text domain. Example: I have this code in my add-on:
and the string "Heavy Infantryman" is added into the generated .po file even though wesnoth-units is not the text domain of my add-on.
About the second issue, the program crashes whenever I run it on add-ons Danse Macabre and For Power (latest version on 1.12 add-ons server). I have no idea why but I am pretty sure that this did not happen in an earlier version.
Thank you again for this nice little tool and I hope that you will be able address these issues as soon as possible.
Code: Select all
#textdomain wesnoth-units
{DEFINE_RECRUIT tank "Heavy Infantryman" _"Heavy Infantryman" "units/human-loyalists/heavyinfantry.png" GOLD FOOD}
About the second issue, the program crashes whenever I run it on add-ons Danse Macabre and For Power (latest version on 1.12 add-ons server). I have no idea why but I am pretty sure that this did not happen in an earlier version.
Thank you again for this nice little tool and I hope that you will be able address these issues as soon as possible.
My content: For Power series
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Ports: Danse Macabre Story of the Wose
Guides: How to translate your UMC
Re: WesPo 2.0
Sorry for replying so late...
...I didn't connect to wesnoth forum for so long time....
During theese day, during my (very little) spare time I am working on fixing some known issues on wespo 2.2.
I fixed 2 of them (one fix actually works and the other is not still tested) and I am working in a specific issue of Macro Call that could be also the explaination of the problem you reported some months ago. I am waiting to release the fixes I already did and see if I can solve also this last problem.
However I will test the issue you reported and see where the problem could be located.
Currently wespo 2.2 has three (four) great problems
now I am working to see if I can solve the last one (two): the one you reported plus this one:
Currently wespo cannot parse wml code inside macro call (in some case you could insert wml code, and so macro call will be a multiline macro call).
I have a possible solution to fix this problem in my mind (that could also solve the problem you reported) but I need to ask an opinion (to you and to all other people interested on wespo project)
1) I can apply my solution exactly as I thinked it, but if it will work, it will create great issues if you use { } signs into strings. So, doing this way, the add-on developers should be awared they should NEVER use { or } signs into any kind of quotation.
esample... never use " { "
2) I can find a solution to avoid this limitation (assuming solution 1 works) but this will mean I need to parse the file twice to prevent it, so the wespo speed of processing .po file will reduced a lot.
So... in your opinion....
is it better to have a quicker .pot generator, that deny add-on developer to use { } into quotations (string, objective text, and so on) or to allow developer to use { } signs into quotations, even reducing a lot the speed of .po generation?
...I didn't connect to wesnoth forum for so long time....
During theese day, during my (very little) spare time I am working on fixing some known issues on wespo 2.2.
I fixed 2 of them (one fix actually works and the other is not still tested) and I am working in a specific issue of Macro Call that could be also the explaination of the problem you reported some months ago. I am waiting to release the fixes I already did and see if I can solve also this last problem.
However I will test the issue you reported and see where the problem could be located.
Currently wespo 2.2 has three (four) great problems
now I am working to see if I can solve the last one (two): the one you reported plus this one:
Currently wespo cannot parse wml code inside macro call (in some case you could insert wml code, and so macro call will be a multiline macro call).
I have a possible solution to fix this problem in my mind (that could also solve the problem you reported) but I need to ask an opinion (to you and to all other people interested on wespo project)
1) I can apply my solution exactly as I thinked it, but if it will work, it will create great issues if you use { } signs into strings. So, doing this way, the add-on developers should be awared they should NEVER use { or } signs into any kind of quotation.
esample... never use " { "
2) I can find a solution to avoid this limitation (assuming solution 1 works) but this will mean I need to parse the file twice to prevent it, so the wespo speed of processing .po file will reduced a lot.
So... in your opinion....
is it better to have a quicker .pot generator, that deny add-on developer to use { } into quotations (string, objective text, and so on) or to allow developer to use { } signs into quotations, even reducing a lot the speed of .po generation?