Hi there,
We’ve got a solution where we’re modifying the localization window to add additional columns (specifically, context.) In order to do that, we had to shift a property in the code called k_startIndex which is the index of the first column that is a language.
However, after doing that, we started to notice that search doesn’t actually work on the first few languages. This is specifically because, in StringTableTreeViewItem, the logic only searches any languages AFTER the start index. This means, by default, when k_startIndex is 2, it will skip the first two locales you have and only add items to the search in the tables after that.
This is because the UpdateSearchString method doesn’t look at all properties, but only looks at the locales themselves, and it seems like there’s definitely a bug there where a bad assumption was made. Essentially, the for loop in that method should be searching ALL of the sorted tables, rather than from the start index to the sorted table count.
Here’s an example. I have added another column that shows the generated search string (this means that my k_startIndex = 4).
In this image, I have 4 columns before we start showing the locales. The default Key/KeyId, my context column, and for the sake of showing it off here, a Search column that shows the ‘displayName’ for the treeview item that is actually used to do the proper filtering and search.
Notice how the English text, Japanese, Korean, and Chinese don’t show up? That’s because the search string generation logic only starts on the index = 4 locale (german), and only adds those to the list. (Note: you will see the english text here because my Key happens to match the english, but that’s not the rule)
The fix is pretty simple.
Change:
for (int i = m_StartIndex; i < m_SortedTables.Count; ++i)
to:
for (int i = 0; i < m_SortedTables.Count; ++i)
And you can now search across all locales. For most users this won’t be as big of a deal, but currently, in the default package, the first two locales are skipped in the searching.