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.

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.