WeiDU should not fail to load mod-related translation strings if executed from a custom working directory

[Argent77]

If WeiDU is executed from a working directory that is not the parent directory of the mod folder then WeiDU fails to resolve translation strings of the mod.

Example for mod /path/to/mymod/mymod.tp2:

cd /path/to && weidu --nogame --list-components "/path/to/mymod/mymod.tp2" 0 results in correctly resolved translation strings.

cd /path/to/somewhere/else && weidu --nogame --list-components "/path/to/mymod/mymod.tp2" 0 results in the following error message for every referenced translation string:

ERROR: No translation provided for @1
Continuing despite error.

/path/to/somewhere/else can be any path except /path/to to trigger this issue.

This behavior affects all mod-related operations, including installing mods.

[FredrikLindgren]

The problem is WeiDU has these two bits of information (using an old version of BP-BGT Worldmap as an example): ./00783/setup-bp-bgt-worldmap.tp2 this is the path of the TP2 file given on the command line, bp-bgt_worldmap/language/english/worldmap.tra this is the path of the TRA file read from the TP2 file. However, WeiDU does not know where the directory "bp-bgt_worldmap/" is unless that is "./bp-bgt_worldmap/".

If the TP2 file is located inside the mod folder, the path to the TP2 file can be used to infer the path to the TRA file, but since that does not have to be the case, it's not a general solution.

[FredrikLindgren]

Thinking a bit more about this, we can reasonably also presume that if the TP2 file is not located inside the same base directory as the TRA files, it's located in the same parent directory, so there are a few guesses WeiDU can make and probably get it right for a majority of times. I'll see if a can find some spot in the code amendable to making guesses.