TranslationDoesnt Translate the First Time
How it Affects Feature: Translation cant be used for new content
When you go to a page from google results, and it recognizes its a different language, Google asks if you want to translate it. For the EASYProcess translation feature, the user has already been set in their user preferences that everything they want to see be in German. So if a page loads and is not in German, it has already failed.
This is the feature working correctly, to EASYProcess though. It will not translate it the first time, but create the dictionary record and the next time it will translate.
So this disconnect means that the translate feature is perceived as either non-intuitive or broken.
Because of this, translation can never be used for new content. If all the text on the application won't change, it is a good tool.
If a manger wants to send out a message "The 160 warehouse will be closed for holiday" to all users, the first German user will receive it and not see it in the proper language, so that would be raised as a bug.
No Site Map to Show Used Sources in Application
How it Affects Feature: Hard for developers to know which sources need to be tested for translation. Developers cant perform full testing.
Suggestion: EASYProcess knows the widgets that open from buttons, etc. This map can be made automatically
The translation task is started by K-Rise developers to see that everything is translating as it should. For small apps this is okay, but for a large app, that has 100 pages/widgets, it is easy to only test the happy path and miss error message windows etc.
We needed a list of sources to say "okay we have to test all these sources" but the full list of webpages/widgets from the IDE are only the ones that exist in the application, not ones that are actually in use.
So we started to use this. There were 178 webpages/widgets in total. The ones marked "DNU" for "Do not use" were obviously not in use. But then there were ones that were much harder to tell. For change password there were:
- Change Password
- Change Password Webpage
- EditAccountSettingsChangePassword
- SetPassword
- ClosedLoginImport
- ClosedLoginPage
- Login
- LoginHeader
So this method of performing the testing was abandoned and the developers tried best to simulate error cases and well as success cases to find all possible pages/widgets. The result was partial testing. It was hard for developers to confirm we had fully tested.
Cant Search for Where Text Appears
How it Affects Feature: Developers cant answer questions of where text appears in the portal
Suggestion: Improve the process lookup page to search UI controls too. There is already a task for improvement on the process lookup page. Could prioritize that task
Once developer testing was over, we handed it over to the IT team for testing. They gave it to the business to test for the new country that would use it. The person doing the translation was not familiar with the portal because it hadn't been released to that country yet because the translation wasn't ready. So they were learning all the pages and how the portal worked also. IT probably walked that person through the portal as an intro then they did their browsing from there.
This is probably a situation we will run into often: the person doing the translation does not know the portal.
So instead of taking the task to be a checklist of all pages and functionality, like someone familiar with the portal or EASYProcess might, the translators created a checklist of all the dictionary records and had to find where they all appeared.
Developers would get questions like "where does 'filter results by' appear" and we would think about where that could display and give our best answers. This took time though and if we didn't think of the answer we might have to give the answer "I don't know, it might not appear anywhere anymore. Maybe it's removed."
This was frustrating for both sides because we all wanted a definitive list of tasks to get through so we could consider the translation testing passed, but when we ran into this situation it pointed more towards the testing being invalid.
This put a lot of responsibility on the K-Rise developers to remove bad dictionary records or else the translator person would not be able to finish their task until all records were accounted for. This also slowed down the process because if they got to record 500/2000 and asked "where does this appear?" and the answer was "that is a bad list you have, here is a new one", they would have to start their tests over again.
No Automatic Initial Translations
How it Affects Feature: Applying each new language will always be as burdensome as the previous
Suggestion: Make it an option on the translation page to auto add a new language by translating an entire dictionary that is given
After one language dictionary was mostly done, it was assumed that it would be faster for the second. However, the final dictionary excel export has the same issues as it did the first time around:
- Developers still don't know the pages/widgets in use to do initial testing to get initial translations
- During testing, translators will see english text for the first time it appears and raise a bug. but really it is functioning as expected.
- Translators will ask where text appears on the portal and developers will have to do a manual search