Translation Sets

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

Parents
  • 0
    Certified Lead Developer

    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.

  • 0
    Certified Lead Developer
    in reply to joh4

    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.

  • 0
    Certified Lead Developer
    in reply to joh4

    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?

  • 0
    Certified Lead Developer
    in reply to joh4

    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

  • 0
    Certified Lead Developer
    in reply to joh4

    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.

Reply Children