Bugs and feedback

We've purchased I2 Localization for use in our current (and hopefully future) projects at work. I'm in the process of testing and evaluating the plugin to ensure it suits our needs.

After using it to localize one of our prototypes, I've come to the conclusion that this has some really great features and a lot of potential, but currently there is quite a number of bugs and workflow issues. Given the feature set, I'd really like to use this plugin, so I'd like to report the issues I've encountered in the hopes that once addressed, this will be our go to plugin for localization. I'm only going to report the bigger issues for now, but there are a ton of other minor bugs and annoyances. All of these are reproducible in 5.2.3f1 and most are reproducible in 5.1.4f1.

Categories cause data loss
Categories are unusable. When you change the Category on a Term, it ends up making a new Term, leaving the old Term invisible in the Language Source, and linking Localize scripts to the new Term. None of the data from the old Term is copied to the new Term, so everything that was previously using that Term is now using an empty Term with no text in it. This happens when creating a new Category

i.imgur.com/eV7MUel.gif

And when attempting to use an existing Category

i.imgur.com/RJaWBE1.gif

Also notice the 'add new Term' button move down way too far when expanding a Term.


Renaming causes data loss
This has a similar problem to Categories. When a Term is renamed, a new blank Term is created and anything that was referencing the old Term now points to an empty Term. You localized data is lost.

i.imgur.com/TwGBgT7.gif

I also cannot rename a Term from the Language Source. I have to open a scene that uses the Term and navigate to a Localize script to do the rename.


Parsing fails to find used but unsaved Terms
When you open a scene that already has Localize scripts on objects, and the scripts haven't been configured (i.e. the script was added, but no Term was added to the Language Source so it's "used but not saved") parsing will not find these Terms/scripts. If I start inspecting these objects in the hierarchy, they will start showing up in the Language Source list of Terms. This means I have a ton of unconfigured Localize scripts just floating around the scene with no way to find them but manually looking through the scene.

i.imgur.com/PvZeVRs.gif

Notice the filter resetting multiple times during that parsing and reopening process.


"Not Localized" Excluded terms is not saved
Not everything is going to be localized. Some text will be set from code and configuring and assigning a Term to them is not necessary. When I search for "Not Localized" items in the scene, I don't want these to show up. To accomplish this, I'm adding "(DNL)" to the names of these objects ("Do Not Localize") and adding "(DNL)" to the exclude list. However, this list is not saved so I end up constantly having to re-add my excluded term every time I want to check for unlocalized objects.


Translate All translates the Term name, not the actual text on an object
Generally, I do not want the Term name to be the exact text that is being localized. The text could be long and there's no reason the Term name needs to be an entire sentence. It's usually more helpful to have a Term name that describes the usage scenario, not the exact content. As such, when I choose to auto-translate, I expect it to translate the actual text content, not the name of the Term.

i.imgur.com/9BiPCFn.gif


Terms on Localize auto-change when changing the placeholder text in the Editor
If the Term on a Localize script isn't manually assigned in the Inspector, it remains in this weird "auto-assigned" state. When in this state, the Term is always exactly what is in the text box. If you change the text, it changes the Term. This is helpful when a Term hasn't been created and saved in the Language Source. But once a Term is set up, this becomes a dangerous annoyance. If I have a Term that is set up and translated and then I go and change the placeholder text, it unlinks the Localize script from the already set up Term. The vast majority of the time, this just ends up breaking localization on that object.

i.imgur.com/1t7uULR.gif


The features in this plugin are absolutely great, but the large number of bugs and quirks currently make the workflow too cumbersome. I'm really looking forward to being able to use this plugin if the above issues are able to be addressed.

Thank you for you time.

Thank you for the fast and thorough reply. Solid support like this carries a huge amount of weight.

Frank wrote:

Categories cause data loss
Renaming causes data loss
Parsing fails to find used but unsaved Terms

All this issues are related to using a Language source instantiated in the scene, instead of using the I2Languages.prefab

This is not true. I originally encountered all of these issues while using the prefab approach and I've just repro'd each of them locally to confirm. I used the scene approach in most of the GIFs because I wanted to use the provided example scenes in an empty project to rule out anything project or implementation specific.

Frank wrote:

"Not Localized" Excluded terms is not saved

Translate All translates the Term name, not the actual text on an object

Your solutions here sound perfect.

Frank wrote:

Terms on Localize auto-change when changing the placeholder text in the Editor

I think that's actually the intended behavior.
When you assign a Localize component, that component its in charge of the Label's text. You shouldn't change that text any longer, if you need to edit the text, you should be changing the localized translation and it will change the label's text.

The terms are kept in the Auto-Assigned state, so that if you create a new term (e.g. Play) and then you want to use it in all labels saying Continue, you just search for that text and change it into Play, that changes the Term to match it.

I'm not sure I understand the proposed workflow here. You're saying you'd search through the UGUI Text components and change the actual text content in them in order to change to the new Term? 1) This seems to run counter to your previous statement that should shouldn't change the text directly once a Localize script is present. 2) This seems like a less convenient and less safe way to make the change. From the Language Source you can already click the number on the left side of a Term to highlight all uses. You can them change the Term from the dropdown on the Localize script.

Frank wrote: But if you still think this is a weird behavior we can evaluate other alternatives.

The thing that makes it weird is that I don't generally expect the Terms and the text content to be the same. For example, the Term may be GameOverMsg while the text content is "You Crashed Your Ship!". When you start working under that assumption, that's when this behavior becomes troublesome.

Frank wrote: What do you think should be the right one? To set the term as soon as any term is found matching the label's text? That could be a problem as when typing Play2, as soon as you type Play it will find Play1 as existing and then when you finish typing the 2 to make Play2, it will not change to Play2.

I don't see another alternative that works fine, but please, let me know if you find a more understandable approach.
But at the moment, the terms has to be manually selected in order for it not to change when the label's text changes.

I think there are a couple small things that could be done that would alleviate this concern.

1) Assume you have an unlocalized Text component. You add a Localize script. The script defaults to an Auto-Assigned state and uses the current text content as the Term. You click Add Term to Source. When you do this, all Localize scripts using this same Auto-Assign Term become fully linked to the Term when it's added to the Source.

2) Assume you have an unlocalized Text component. You add a Localize script. When added, the Localize script checks the Source and if there is a Term that uses the exact text content, it becomes fully linked to the existing Term.

This, imho, is far more intuitive. When I add a Term that's being used, I instinctively expect all scripts using that Term to be linked to it unless explicitly told to change. I agree that the Term probably doesn't need to attempt to fully link while typing in realtime. That would likely be awkward.

Frank wrote: I will be implementing all the changes I mentioned as soon as I get back home and will keep you updated.
Hope that helps, and please, don't hesitate in letting me know if any other suggestion!!

Excellent, thank you very much. I'll be providing more feedback in the future, but I didn't want to blast you with nitpicky things right out of the gate. These are the important ones for now.

Categories, renaming and parsing are all still broken. Changing Categories now throws an exception. I've recorded a video demonstrating the problems.



You can see renaming blow up a Term at 0:50 and 2:02
You can see changing Category throwing an exception at 1:08 and 1:38
Reopening the scene at 2:12 causes 'used but unsaved' Terms to disappear
Parsing fails to find those Terms at 2:20
The Terms reappear after I manually inspect objects in the Hierarchy at 2:27