Bugs and feedback

More
8 years 3 months ago - 8 years 3 months ago #1138 by Sycobob
Bugs and feedback was created by Sycobob
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.
Last edit: 8 years 3 months ago by Sycobob. Reason: GIFs don't work here

Please Log in or Create an account to join the conversation.

More
8 years 3 months ago #1139 by Frank
Replied by Frank on topic Bugs and feedback
Hi,
Thanks for using the plugin and reporting this issues. My main priority has always been fixing bugs asap so I will be tackling those next. And please, don't hesitate in sending me more issues you are find (no matter how small) as that way I can have fix them!

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
It is recommended that you do not add a LanguageSource in the scene, but instead, click in the I2Languages.prefab and edit its content. That prefab works as a Global language source accessible everywhere, (no need to instantiate it)

LanguageSources as part of the scene should only be used for specializing a few terms that are only going to be used in the scene. The Example scenes are using it so that its localization doesn't conflict with the localization in your project or in other examples, but should be using I2Languages.prefab 99% of the time.

Said that, Its a bug that if a language source tries to rename one of its terms, it gets added into the I2Languages.prefab instead of just editing the one in the instantiated source. I will fix that asap

"Not Localized" Excluded terms is not saved


I see your point, so I'm going to add two things:
- A checkbox in the term to mark those that are used from the code (and so they shouldn't show in the No Localized searches)
- Save the filters so that you don't have to type it everytime

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


This is not actually a bug, but definitely can be improved.
How the translate all works, its that it tries finding one of the translations that you already typed, and translate that into the rest of the languages. So, you have to at least write the text for Spanish or English (in your image) and it will use that text for translating into the other languages.

If there is no text in any language, then the plugin just picks the Term name (thats what you are seeing).
That can be improved, so I will make it that it takes the text from the label and only if that text is also empty it will use the Terms name.

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.

But if you still think this is a weird behavior we can evaluate other alternatives.
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 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!!

Frank

Are you :-) Give I2L 5 stars!
Are you :-( Please lets us know how to improve it!
To get the betas as soon as they are ready, check this out

Please Log in or Create an account to join the conversation.

More
8 years 3 months ago #1140 by Sycobob
Replied by Sycobob on topic Bugs and feedback
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.

Please Log in or Create an account to join the conversation.

More
8 years 3 months ago #1141 by Frank
Replied by Frank on topic Bugs and feedback
Hi,
I added fixes to most of the issues you reported.
The new version (2.6.2 b1) can be downloaded from the beta folder.

Among the changes you can find:

NEW: When editing a term, Translate and Translate All buttons will translate the Label's text instead of the Term name
NEW: Tool to find No Localized objects now saves the Include and Exclude filters
FIX: Changing Term Categories or Renaming it will now update the language Source
FIX: Add button (+) after the Terms list is now always at the end of the terms, even when a term is expanded

Hope that helps!
Frank

Are you :-) Give I2L 5 stars!
Are you :-( Please lets us know how to improve it!
To get the betas as soon as they are ready, check this out

Please Log in or Create an account to join the conversation.

More
8 years 3 months ago - 8 years 3 months ago #1149 by Sycobob
Replied by Sycobob on topic Bugs and feedback
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
Last edit: 8 years 3 months ago by Sycobob.

Please Log in or Create an account to join the conversation.

More
8 years 3 months ago - 8 years 3 months ago #1150 by Frank
Replied by Frank on topic Bugs and feedback
Hi,
You are really good at finding corner cases haha. Most of those issues are because of having two inspectors open at the same time.
I added checks for that case and created a new version with the fixes (2.6.2 b2) please download it from the beta folder.

You can see renaming blow up a Term at 0:50 and 2:02


Terms are not really been lost, the thing it's that the list displayed in the LanguageSource inspector its actually a cached list that includes no only the terms in the source, but also the terms found in the scene (missing, not included, etc).
That cached list its updated when the language source editor is opened, but given that you leave it open while doing operations with a different inspector, then the list is not updated until doing an operation in the language source inspector.

Parsing the scene its an expensive operation (as it has to iterate all objects in the scene, and other scenes if selected) so I tried running that whenever an operation happens in the Localize inspector as well, but I found it a bit slow to parse all the time, so I just leave it just for some cases.

Nonetheless, I added now that whenever you rename/categorize something in the inspector of the localize component, it parses the terms and updates the cache. So this first issue you reported its now fixed.

You can see changing Category throwing an exception at 1:08 and 1:38


What happened there is also because of the multi inspectors. After you renamed the term, it was missing from the cache, and you tried changing the category of a missing term.
I added a fix for that as well. Now given that it parses after renaming, it won't be in a bad state, but if for some other reason it gets to a bad state, instead of an exception, it will display a message in the inspector showing that it failed, why and how to solve it (parsing the scene).

The second exception you saw, was because the cached source was already in a bad state and given that the inspector was closed/opened, then it didn't regenerate its internal cache.

Reopening the scene at 2:12 causes 'used but unsaved' Terms to disappear
Parsing to fail to find those Terms at 2:20
The Terms reappear after I manually inspect objects in the Hierarchy at 2:27


Again, for all the missing terms to show, the scene has to be parsed, which its not done regularly for performance reasons.
However, its tedious to have to do Tools \ Parse Scenes, so I went an added a Refresh button on top of the term list.





Whenever you want to update the list with all the terms in the scene, just click the button. If you also want to see the terms used in other scenes, then you have to go to the Tools tab and select parse scenes while selecting ALL or manually selecting the scenes you want to be checked.



Hope that helps, and please, keep sending me any other issue you see and I will try fixing it asap.

Thanks,
Frank

EDIT: Also please, notice that if the GameObjects are disabled, unity will not report them when executing FindObjectsOfTypeAll<Localize> until you step over them so that unity internally "load" them.
That may also be causing some of the terms not showing after the scene is loaded.

Are you :-) Give I2L 5 stars!
Are you :-( Please lets us know how to improve it!
To get the betas as soon as they are ready, check this out
Attachments:
Last edit: 8 years 3 months ago by Frank.

Please Log in or Create an account to join the conversation.

Time to create page: 0.235 seconds
Template by JoomlaShine