OK, created IDEMPIERE-6319

Yes, option 2.

Thanks - do you mean option 2?

I think create just the prefixed variable is safe and straightforward. If we change the behaviour of the Msg.translate call, it is not backward compatible either.

I think we have a problem here with any call to Msg.translate on the user preferences:
AutoCommit, AutoNew, AutomaticDecimalPlacesForAmoun, IsDetailedZoomAcross, IsReadOnlySession, IsShowTechnicalInfOnHelp, IsUseSimilarTo, ToggleOnDoubleClick, ViewFindResult

The problem here is that every preference is set on the global context, so, calls to Msg.translate using one of those keys will return the content of that context variable instead of the expected columnname translated.

And this problem is just going to grow as creating user preferences is easy and expected, and is extended to plugins that can create their own user preferences.

NOTE aside: I tried another approach to make the Msg.translate have a different preference -> Msg/Element/Context - but then there is a message with name "AutoCommit" and it was returned with the msgtext plus the msgtip - it looks weird too.

So, we are having a big issue there, two possible solutions:

1 - we can define a standard prefix for preference columns to minimize collisions with context, for example any column name in AD_UserPreference table must have a prefix PREF_ - like PREF_AutoCommit - this can be applied for future preferences, or make it retroactive and change the actual preferences with a migration note because is potentially breaking some plugins

2 - we can change the preference approach to NOT create a context for the preference. At this moment every preference creates two context variables, plain and with P| prefix, f.e. AutoCommit and P|AutoCommit
if we create just the prefixed variable then the problem is solved, but again is not backward compatible, we would need a migration note as potentially breaking plugins

WDYT?