However, since Italian is not my native language, my translation is kind of... lets say sub-standard

Moderators: winston, another_commander
Nice!another_commander wrote:Both these are resolved in the version I'm working on. I can send you the files I currently have, as an example, if you want. The idea is that you are not replacing the definition keys, but only the strings containing the names displayed in the game.
Oh, yes. I should've been aware of this. Very nice if you can solve it.But now, I've bumpled into another problem: I cannot replace original equipment items. The problem is similar to Cmdr Maegil's oxp missiles. The translated equipment items are not replacing the standard ones, they are added on top of them. So, I have both the English and Italian version of all standard equipment. This is due to the way Oolite is building the equipment list. I am looking into it at the moment.
Me wrote:I've run into another problem: commodities. We cannot translate them, as they are identified and called for by their names. So if I rename Firearms to Waffen, they're no firearms anymore.
Only solution to that: the current name of the commodities would have to be converted into a mere identifier. Then in a second step a freely choosable namestring would have to be attached to this identifier.
I don't think you have resolved this. In case of the commodities the "strings containing the names displayed in the game" are the "definition keys". That's why I made the point that you have to create a definition key, which then in the second step gets a namestring attached to it. This means a reprogramming of the code, a new commodities.plist isn't enough!another_commander wrote:Both these are resolved in the version I'm working on. I can send you the files I currently have, as an example, if you want. The idea is that you are not replacing the definition keys, but only the strings containing the names displayed in the game.
Code: Select all
<array>
<string>Food</string> <-- Name
<integer>0</integer> <-- Quantity at market
<integer>0</integer> <-- Price at market
<integer>19</integer> <-- Base price
<integer>-2</integer> <-- Price adjustment
<integer>-2</integer> <-- Quantity adjustment
<integer>6</integer> <-- Base quantity
<integer>1</integer> <-- Price mask
<integer>1</integer> <-- Quantity mask
<integer>0</integer> <-- Units
</array>
Code: Select all
<array>
<string>Food</string> <-- Identifier
<string>Cibo</string> <-- Name
<integer>0</integer> <-- Quantity at market
<integer>0</integer> <-- Price at market
<integer>19</integer> <-- Base price
<integer>-2</integer> <-- Price adjustment
<integer>-2</integer> <-- Quantity adjustment
<integer>6</integer> <-- Base quantity
<integer>1</integer> <-- Price mask
<integer>1</integer> <-- Quantity mask
<integer>0</integer> <-- Units
</array>
No. This is utterly user-unfriendly. Who is taking care of backward compatibility? Your Italian user won't be able to use any existing script anymore. (At least none that does anything with cargo.) He would be confined to those scripts only whose creators choose to do an Italian language version as well. Completely unrealistic.another_commander wrote:...It is the responsibility of the scripters who want to create a script in a different language to use the correct commodity types for that language. The engine does not need to translate anything, as the commodity name will be provided by the scripter in the language being used.
Any script outside the core game ones will need to be redone, because any existing messages will have to be translated, so script editing will occur one way or another. If one will have to edit anyway, might as well edit the commodities. As a first step in the attempt I have made, I have set a target to get the standard game working. OXPs are a secondary target. But I will consider the solution you are proposing. Although it would defeat the purpose of localizing the game, I can see that a non-English speaking user might not care about messages and might just want to try out an oxp regardless of the language used. I'll have a look into the feasibility of the solution you are suggesting and will apply it if possible. But not before I've taken a couple of days offCommander McLane wrote:Your Italian user won't be able to use any existing script anymore. (At least none that does anything with cargo.) He would be confined to those scripts only whose creators choose to do an Italian language version as well. Completely unrealistic.