I'm just looking at the new functionality in the release notes for 23.4 and 24.1 and I see Translation Sets that allow you to translate your applications to another language. The walkthrough on the release notes show going in to an interface, clicking a button to generate strings which get put in to the translation object that then you export as excel and send to your translators, to which they fill out, send back, and then you re-upload.
But I'm confused about a few things.
1. Our application has over 100s of interfaces, do we need to go through each interface and click this button?
2. If we do that, it's only getting the strings where the text is hardcoded as string values on the interface. We have always put our labels, instructions, etc in constants so that if we ever have to change verbiage we can just change the constant instead. This functionality is not picking up the constants? Is it expected that we remove all constants and go back to literal strings on the interfaces? We have over 1,000 constants throughout the application, most named properly to identify ("TEXT_LABEL") but that doesn't seem like a good idea to do that? Am I missing something?If anyone has any thoughts, please let me know.
Thanks
Discussion posts and replies are publicly visible
Quick answers: Yes, and Yes.
If you need to add multiple language support to your app, then you would have to rework everything anyways.
And you can manage translation sets and strings without clicking that button. It is just a small helper to start more quickly.
So if I go in to an interface, and one of my labels is a constant - the idea would be to replace the constant with the text string, then turn it in to a translation variable. Then that spot that was a constant, then a string, would now be a translation string. And the translation set would act as essentially as a new way of managing these constants? So that if I ever need to change a label, I can just change it in the translation set (english and french) and it will reflect on the form.And with that design pattern, going forward, translation sets will somewhat also act as a list of constants for lack of a better word - references to spots in the application, where you can go in to the translation set, change a value and it will reflect in the form?Sorry, I'm just trying to fully understand - my application is massive, built by many people over the years and now I am supporting it. There's over 1000 interfaces across our combined apps, and a design practice was to always make labels and instructions in to a constant so that they can easily be changed - now, I just want to make sure that the correct approach here is to basically unravel these constants in to strings, turn in to translation strings managed in a translation set and use that translation set as the way we manage labels and instructions, etc.
Right, and therefore, not for just straight up replacing constants, right?
A dynamic value is meant for something dynamic (something in the database or a process). A constant is is usually mean for something not dynamic. So I would say no.
This is actually the first time I ever see an app with labels stored in constants. Prior to translation sets, we used resource bundles: community.appian.com/.../load-resource-bundle
Dynamic translations are NOT created with your idea in mind. So, while it probably will work, I assume that internal testing at Appian will not focus on this specific use case.
Not my idea, but a coworkers, just wanted to get other feedback from the community to show him and dissuade from going that approach. Thank you.
Interesting. I guess I only know the applications of my internal team, haven't really seen what other organizations are doing. I was always under the impression that it was best practice to have labels and instruction text as constants. But I guess, now that multilingual applications are coming in to the picture, that doesn't really make sense. Thanks.
One last question. Since I have an application with 1000+ interfaces and constants in the spots everywhere for labels and instructions. What is the best approach to identify those spots? Is it just going in to each interface one by one and just looking line by line? Crtl F'ing for 'label' or 'instructions' or 'cons'? - I had another team member mention a plug-in that can be used to identify the spots - they instructed to use this to atleast identify the labels and instructions - https://community.appian.com/b/appmarket/posts/application-translator - but I havent done anything with it yet and I don't even know if using this plug in from 4 years ago really makes sense.Thanks again.
That plugin will not help you in refactoring your apps to make use of translation sets. BTW, do you need to do that? If not, either continue with what you are doing now, or refactor objects when touching them to the new style of choice.
The ask is coming in to refactor the whole application. In regards to government in Canada requiring language to be french canadian. They want the application to be in both english and french now. Understood the plugin wont actually do the refactoring, (and apologies, I havent looked much in to it yet) but will it scan the application for everything and then make a excel sheet, then I can make that the translation set as a starting point. When I go in to my first interface, I could just delete the constant for say "Manage Documents" and just type translation!ManageDocuments and it will link to that in the Translation Set?
Did you try the built in feature to create translations automatically from existing interfaces?
It only works with hardcoded strings, does not pick up constants.
OK. Good to know. I never tested that plugin, but checked the documentation. AFAIK it tries to create property files. But I have no idea whether it picks up constants.