GlobalLanguage() must be implemented through the "Translation Helper" codeunit

[Arthurvdv]

The goal is to less use the GlobalLanguage() function directly and implement this through the "Translation Helper" codeunit of the Base Application. This is similar to #205.

This benefits mostly in a more readable code:

Bad code

local procedure MyAwesomeFunction()
var
   GlobalLanguageInteger: Integer;
begin
   GlobalLanguageInteger:= GlobalLanguage;
   ...
   Some code here
   ...
   GlobalLanguage(GlobalLanguageInteger);
end;

Good code

local procedure MyAwesomeFunction()
var
   TranslationHelper: Codeunit "Translation Helper";
begin
   TranslationHelper.SetGlobalLanguageById(GlobalLanguage);
   ...
   Some code here
   ...
   TranslationHelper.RestoreGlobalLanguage();
end;

Source: https://github.com/StefanMaron/MSDyn365BC.Code.History/blob/master/BaseApp/Source/Base%20Application/TranslationHelper.Codeunit.al

[fvet]

@Arthurvdv @StefanMaron Looking into the documentation part of above mentioned codeunit, I read

// This functionality should be provided in the platform and this codeunit should be deleted.

Is it worth the effort (no of lines / readability of bad vs good is the same) of reviewing our code for the new rule?

Maybe the default severity for the new LC0022 rule could be set to none?

[StefanMaron]

Isnt using the one we have now still better than writing the code yourself? And if it gets implemented in the system app, that should be quick to refactor?

[Arthurvdv]

Indeed, I’ve doubted if I should wait for refactoring to the system layer or point to the current codeunit. I can't see into the future (where’s that magic crystal ball?) and I’m guessing refactoring from the old to the new codeunit could be more easier then refactoring from the built-in function. And in the time between we benefit from more readable code.