When the word count is wrong in the localization dashboard
Conclusion
This is because the texts before translation and texts after translation of native culture are different. Keep it the same value.
Details
First, it’s good to know the order in which localization data is processed: Link
Let’s look at the step immediately after collecting the texts in more detail.
Here, if we change the text ([B]Gathered texts) after translation of the native culture translation file (.archive), it becomes as follows.Here’s where I got confused.
The text that comes in the text before the translation of the non-native culture translation file (.archive) becomes the text after the translation [B] of the native culture translation file (.archive).
It is not a text before the translation of native culture [A].
The text after the translation [B] of the native culture translation file (.archive) is synchronized by being copied to the text before translation ([C], [E]) of all non-native culture translation files whenever it is changed. (Please note that if the text was in the translation completed state after translation, the item will return to the Needs Review state.)
Although the probability of it happening should be very low, by modifying, if the text after the translation of the native culture translation file (.archive) has a different value from the text before the translation, it will be excluded from the word counting by the process below.
In FLocTextHelper::GetWordCountReport() GitHub Link the part where we actually count the words here: GitHub Link Here, for each culture, words are counted by iterating through the items in the manifest.
In here, this FLocTextHelper::GetExportText()
GitHub Link
function makes the problem. At the beginning of this function, by OutSource = InSource;
, in manifest, copy the words gathered to OutSource
. And if we look in the middle, you will see the code below.
GitHub Link
It is checking whether the text before the translation of the translation file (.archive) matches the collected text saved in the manifest.
However, as mentioned earlier, if we modify the text after the translation of the native culture translation file (.archive), the text before the translation of the translation file (.archive) in each non-native culture becomes the text after the translation of the native culture translation file (.archive). That is, this check always fails.
For example, if the state immediately after text collection was:
Item | Example value | Location |
---|---|---|
0. Gathered text | TextsGathered | .manifest |
1. Text before the translation in the native culture | TextsGathered | .archive |
2. Text after the translation in the native culture | TextsGathered | .archive |
3. Text before the translation in the culture to work | TextsGathered | .archive |
If we modify the text after the translation of the native culture, it will look like this:
Item | Example value | Location |
---|---|---|
0. Gathered text | TextsGathered | .manifest |
1. Text before the translation in the native culture | TextsGathered | .archive |
2. Text after the translation in the native culture | TextsModified | .archive |
3. Text before the translation in the culture to work | TextsModified | .archive |
If the values of 0 and 3 are different, it is excluded from counting. The value of 3 is synchronized with 2. So, if you change the value of 2, it will be excluded from counting.
Please note that this part does not affect compilation. The results of word counting are incorrect, but the words are included correctly in the compiled localization file (.locres) at compile time. For this reason, it wasn’t easy to find the problem.