Translation Sets

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.

Yes. Translation sets are the place to store labels, if, and only if, you need these to be dynamic and/or in multiple languages.

Thank you very much. I appreciate the response. If you don't mind I just want to ask one more thing.

When I first brought this up, a team member had mentioned that in release 24.1 - they were introducing dynamic values to translation strings - which would help the constant case I have.

They suggested an approach like this




But this wouldn't make sense to me. It doesn't seem like the dynamic translation variables are for constants, but rather more so like peoples names or something.

If I used the above approach, Updating the constant would just cause the english version to update and then I would have to go to the translation set and update the french version - whereas, if I just do the translation string, whenever I want to update, I would go to translation set.

Could you confirm or give feedback on this? This is clearly not intended or the right approach for constants right? By doing  this -  I'm just making it harder to keep things in sync.

Thanks again for feedback.

Dynamic values are meant for anything that can be replaced within text (dates, names 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.

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. 

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.