Fixed Preprocessor fails to translate item names

[Grey Roger]

The preprocessor works for item descriptions but not, apparently, for item names. So, from "itemsDescribe.txt",

itmname_letter_to_bernard   {Letter for #sFatherBernard#}
itmdescr_letter_to_bernard
{
A letter from Padre Domingues to #sFatherBernard#.
}

shows up as "Letter for" and "A letter from Padre Domingues to Padre <RandomName>".

 

[Levis]

Is it preprocessor or translation?
Did you add the attribute FatherBernard to the item or should it look up the translation of FatherBernard?

 

[Grey Roger]

It should look up the translation which is currently defined by @Pieter Boelen's code in "Periods.c". And it does look up the translation for the description; only the item title fails to translate.

As I recall, @Pieter Boelen had to do something to make the description work properly so that "Spanish Letter", which you get during the "Vogelstruijs" sidequest, displays the correct name for Santo Domingo when the town is French Saint Domingues. Whatever was done may need to be done again for item names.

 

[Levis]

I see, will check the code when I'm home, don't have the inverntory interface file here.

 

[Pieter Boelen]

Again? Really?

Which interfaces are affected by this? The Inventory screen at least, I imagine, but how about the Item Trade and Item Exchange ones?
Do they all have the same problem?

 

[Grey Roger]

No idea. It's a quest item so it can't be traded or exchanged. Unless there are any non-quest items which have, or may at some time need, translatable names then it won't be a problem in the trade or exchange screens.

 

[Pieter Boelen]

No idea. It's a quest item so it can't be traded or exchanged. Unless there are any non-quest items which have, or may at some time need, translatable names then it won't be a problem in the trade or exchange screens.

Can you change it to a normal item and Reinit for testing purposes?

 

[Grey Roger]

What did you change to fix it last time so that item descriptions are properly translated?

 

[Pieter Boelen]

What did you change to fix it last time so that item descriptions are properly translated?

Something with the order in which XI_ConvertString and/or TranslateString and/or PreprocessText(sp?) are called.
In this case, the relevant file is PROGRAM\INTERFACE\items.c .

 

[Levis]

Will check it soon. I use it for the patrolbooks too and there it works so might be a check for quest items or something.

 

[Levis]

Place these in the interface folder. This should fix it.

An idea tough, Why not add the preprocess text function to the translate function?

 

[Pieter Boelen]

An idea tough, Why not add the preprocess text function to the translate function?

Isn't it already there? I thought it was in some shape or form....

 

[Levis]

Seems not ... and if so it's not working right

 

[Pieter Boelen]

I'd be fine with it being added there. Saves many nested function calls.

TranslateString could perhaps do with some more optimizing. I remember removing it from the Select Storyline search functionality because it REALLY slows things down when called in batch.

 

[Pieter Boelen]

Seems not ... and if so it's not working right

This is the fix I did before:

    if( GetAttribute(itemARef,"groupID") == MAP_ITEM_TYPE)
     {
       itmDescribe = GetAssembledString(itmDescribe,itemARef) + GetAssembledString(TranslateString("", itemARef.describe), itemARef) + GetItemBonuses(itemARef.id); // NK
     }
     else
     {
       itmDescribe = GetAssembledString(itmDescribe,itemARef) + PreprocessText(TranslateString("", itemARef.describe)) + GetItemBonuses(itemARef.id); // PB
     }

Can't remember now what the if-case is for; would be nice if we could get rid of that.

For your fix, this:

    GameInterface.strings.ItemName = GetAssembledString(TranslateString("", itemARef.name), itemARef); // KK

Was replaced with:

    GameInterface.strings.ItemName = GetAssembledString(PreprocessText(TranslateString("", itemARef.name)), itemARef); // KK

However, this is what PreprocessText does:

string PreprocessText(string text)
{
   ref pd; makeref(pd, PreprocessorData);
   aref pdat; makearef(pdat, pd.data);
   return GetAssembledString(text, pdat);
}

It calls GetAssembledString again, so do we really need to do that again? GetAssembledString is some sort of "native function", so I've got no clue what it does.
TranslateString indeed doesn't contain any preprocessing.

 

[Grey Roger]

This is the fix I did before:

    if( GetAttribute(itemARef,"groupID") == MAP_ITEM_TYPE)
     {
       itmDescribe = GetAssembledString(itmDescribe,itemARef) + GetAssembledString(TranslateString("", itemARef.describe), itemARef) + GetItemBonuses(itemARef.id); // NK
     }
     else
     {
       itmDescribe = GetAssembledString(itmDescribe,itemARef) + PreprocessText(TranslateString("", itemARef.describe)) + GetItemBonuses(itemARef.id); // PB
     }

Can't remember now what the if-case is for; would be nice if we could get rid of that.

It appears to be saying that if the item is a map, use 'GetAssembledString', otherwise use 'PreProcessText'. This makes no sense unless the assembled string is preprocessed somewhere else because if there's one type of item which needs both name and description preprocessed, it's a map, e.g.

itmname_mapIsland {#slocation# map}
itmdescr_mapIsland {
Map of #slocation#.
}

So maps must have their names and descriptions preprocessed.

 

[Pieter Boelen]

It appears to be saying that if the item is a map, use 'GetAssembledString', otherwise use 'PreProcessText'. This makes no sense unless the assembled string is preprocessed somewhere else because if there's one type of item which needs both name and description preprocessed, it's a map, e.g.

itmname_mapIsland {#slocation# map}
itmdescr_mapIsland {
Map of #slocation#.
}

So maps must have their names and descriptions preprocessed.

Looking at it further, I think I understand it again.
GetAssembledString is called WITH the itemARef attribute, which contains a .island attribute which is probably used to preprocess the text.
Note that the maps use "#slocation# map" instead of the more regular "#sRedmond# map" as you often see in dialogs or quest texts.

So by that reasoning, indeed these functions DO all three need to be nested because PreprocessText does the normal preprocessing and GetAssembledString does the itemRef-based preprocessing.
Probably my if-statement could be replaced with @Levis' nested single-line solution as that should hopefully cover all bases.

 

[Levis]

For your fix, this:

    GameInterface.strings.ItemName = GetAssembledString(TranslateString("", itemARef.name), itemARef); // KK

Was replaced with:

    GameInterface.strings.ItemName = GetAssembledString(PreprocessText(TranslateString("", itemARef.name)), itemARef); // KK

However, this is what PreprocessText does:

string PreprocessText(string text)
{
   ref pd; makeref(pd, PreprocessorData);
   aref pdat; makearef(pdat, pd.data);
   return GetAssembledString(text, pdat);
}

It calls GetAssembledString again, so do we really need to do that again? GetAssembledString is some sort of "native function", so I've got no clue what it does.
TranslateString indeed doesn't contain any preprocessing.

GetAssembledString searches the text for #things if it finds one it searches the attributes from the given reference and if it finds one it replaces it.
So the more preprocessorData you add (and don't remove) the slower the game will be.
That's why for example the Smugglerbooks have the islandname etc attached to the item itself. This is what the GetAssembledString is for. I believe I've added that a while ago already so you could add things to the item instead of the preprocessor.

TranslateString has to search trough all different translation files which are set to be searched. That's why I sugested already to check those and remove dublicates.
Also we might want to split the translate function to for example TranslateIslands, TranslateTowns, TranslateInterface
etc so we only have to search 1 file instead of more.
But this would require a lot of search and testing to see if we got the right file etc.
So I sugest we keep that for build 14.

 

[Pieter Boelen]

So I sugest we keep that for build 14.

15

 

[Pieter Boelen]

Reopened:

I'm afraid my method may be required then. @Levis, can you take care of that by any chance?