Question Using :U with character strings

Rob Fitzpatrick Sponsor
For some years now our developers have been in the habit of appending ":U" to the end of certain character strings in code. E.g.:

if foo = "bar":U then
  run baz.p
The docs say this makes the string untranslatable by OpenEdge Translation Manager. We don't use this product and, to my knowledge, never have. I guess the thinking was that if we ever did use it, we wouldn't have to go back and change all the code to add ":U" everywhere.

Now that Translation Manager is listed as "de-supported" in OE 12.x, it's pretty much guaranteed that we will never use this product. Assuming that's true, is it now a pointless exercise to be adding ":U" to character strings in code? Or does ":U" have some other magical, undocumented purpose?


It was always a bad idea. :U should have been the default and translation should have been something you requested.

Anyhow... IMHO it is now even more pointless than ever.

Cringer Moderator
Staff member
We actually allow use of the Translation Manager, so all our Strings have it on. We even have a SonarQube rule to enforce it!!
But yes, other than the Translation Manager it has no added value.


I have the feeling I'm not totally clear what the Translation Manager actually is.
Is it a GUI tool to define the translations, or is the ability of the compiler to use the xlatedb and include translations in the .r files part of it? We use our own tool which operates on the XL_* tables in the xlatedb, but of course we still depend on the compiler to access the xlatedb and translate the strings at compile time.
We don't use SonarQube (yet), but we have optional checks at compile time to ensure all strings have a string attribute.

I also think :U would have been a much better default. Most code would look cleaner, and the default using the length of the given string isn't helpful at all.


OK, I think my question was answered:

For release 12.0.0, the Translation Manager and Visual Translator were removed from the product.

However it is still possible to use the r-code multi-Text-Segment based AVM built-in string-translation mechanism including the compiler features:
compile x.p string-xref, the translation Database (project database) and the compile x.p languages (<list of languages>) with connected translation database for creating language specific r-code text-segments.
OE 12.0 r-code still provides the ability to have multiple text-segments for providing multiple languages.


Labels are certainly being translated at compile-time and the translations are included in the r-code. The KB entry I mentioned (I didn't open a call, just stumbled upon it) says that this will still work.
If that doesn't answer your question you might have to be more specific.