Dynamics AX handles text localization by using a label ID (e.g. @SYS1234) in code and metadata; the real text is looked up then based on user’s language. .NET developers may recall localization resources and satellite assemblies and it’s indeed a very similar principle.
There are few changes in Dynamics AX 2012 regarding labels, mostly because of the movement of application files to database (model store). Labels are now located in AOT (Label Files node) or – from another perspective – in ModelElementLabel table in database.
New label files are still created by Label file Wizard, but the existing ones are imported and exported in AOT, not as before by direct manipulation with .ald files in the application directory.
This alone is a quite confusing change for many people and even more radical changes were made for labels saved in a version control system.
If you create a new label, let’s say in the ABC label file, ID of the new label is @ABCx (e.g. @ABC42). It was exactly the same in previous versions too.
But if a version control is active, it’s different.
In case of active version control, a temporary label ID is created at first. It looks somehow like @$AA1 (I think one temporary label file is created for each user-defined permanent file – sequentially from AA to AB, AC etc.).
This temporary ID is replaced by a “normal” ID (i.e. ID corresponding to the label file name) when inserting to the version control. Label ID is replaced also in code and metadata, but only if these objects are checked into version control together with the label file.
What are these temporary IDs good for? If every developer has his own Dynamics AX environment (as recommended), it’s necessary to guarantee that no duplicated IDs are created on different places. It used to be accomplished by Team Server which centrally assigned individual IDs. The current solution doesn’t require any central component for development; each environment assign label IDs by its own. Only when inserting to version control, permanent label IDs are assigned, which is a serial operation without any risk of ID conflict.
Version control in Label editor
Version control commands are accessible from Label editor. They work similarly as for other objects (labels are saved in version control as good old .ald files), just be sure that the right label file (field Label file ID) is selected.
And what if I don’t check in code and labels together?
Let’s show it by an example:
I create two labels and code using them. Notice that they are temporary IDs prefixed by @$:
I insert the code to version control but I forget the label file:
Code is saved to version control without any change and thus using temporary IDs:
Such code obviously won’t work correctly in other AX instances. But if I check in the code again, now with the label file:
temporary IDs are correctly replaced. You also get an infolog message enumerating changed objects:
Another situation arises if you insert labels to version control, but omit some code. All code not included in the check-in stays the same and continue to use temporary IDs. Fortunately, it’s not difficult to find the right permanent label, because the text of the temporary label is changed to contain such information:
However, the fix must be done manually.
No matter how we achieved the goal, now we can run the code with correct labels:
Will this also work when the label files are located in another model? Thus the application objects are located in another model.
Yes, this works too. I don’t think AX cares about models in this whole logic.