Skip to content

Conversation

@romanett
Copy link
Contributor

@romanett romanett commented May 18, 2025

Proposed changes

The OPC UA Spec Part 3 (https://reference.opcfoundation.org/Core/Part3/v105/docs/8.5) describes the Support for a special 'mul' locale. This PR adds support for this 'mul' locale.

If the LocalizedText class is now initialized with a 'mul' local the new Property IsMulitiLanguage is set to true and the new Property Translations contains a Dictionary of strings with the different locales / texts extracted from the JSON in the Text Property.

Also a new Constructor was added which takes a dictionary of strings to initalize a new 'mul' locale text. This constructor automatically creates the needed json.
The Translations Property can also be set and a 'mul' locale with sufficient text is created.

Also the translation manager is adapted to return only requested locales if a 'mul' locale string is provided and also support 'mul' locae requests by the client, as described in https://reference.opcfoundation.org/Core/Part4/v105/docs/5.4.

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • Enhancement (non-breaking change which adds functionality)
  • Test enhancement (non-breaking change to increase test coverage)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected, requires version increase of Nuget packages)
  • Documentation Update (if none of the other choices apply)

Checklist

  • I have read the CONTRIBUTING doc.
  • I have signed the CLA.
  • I ran tests locally with my changes, all passed.
  • I fixed all failing tests in the CI pipelines.
  • I fixed all introduced issues with CodeQL and LGTM.
  • I have added tests that prove my fix is effective or that my feature works and increased code coverage.
  • I have added necessary documentation (if appropriate).
  • Any dependent changes have been merged and published in downstream modules.

@codecov
Copy link

codecov bot commented May 18, 2025

Codecov Report

Attention: Patch coverage is 72.80000% with 34 lines in your changes missing coverage. Please review.

Project coverage is 57.47%. Comparing base (d831232) to head (7873085).
Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
...aries/Opc.Ua.Server/NodeManager/ResourceManager.cs 53.84% 14 Missing and 10 partials ⚠️
Stack/Opc.Ua.Core/Types/BuiltIn/LocalizedText.cs 86.30% 5 Missing and 5 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #3076      +/-   ##
==========================================
+ Coverage   57.36%   57.47%   +0.10%     
==========================================
  Files         357      357              
  Lines       69015    69113      +98     
  Branches    14164    14201      +37     
==========================================
+ Hits        39593    39721     +128     
+ Misses      25180    25147      -33     
- Partials     4242     4245       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

…les provieded to Resource Manager (return only requested locales)
@romanett romanett changed the title Implement support for "mul" locale in LocalizedText Class Implement support for "mul" locale in LocalizedText Class & ResourceManager May 20, 2025
@romanett romanett requested a review from mrsuciu May 22, 2025 07:01
Copy link
Contributor

@mrsuciu mrsuciu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not know exactly if {"t":[["en-US","Hello"],["de-DE","Hallo"]]} should be considered the same as {"t":[["de-DE","Hallo"],["en-US","Hello"]]}. Semantically I would say they represent the same translations. If this is true than LocalizedText.Equals and LocalizedText.GetHashCode methods should be changed to take this into account and operate on the translations not the string.

t = string.Format(table.Locale, t, info.Args);
}
catch
{ }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be at least logged ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the old implementation it was ignored as well and just the old text used formattedText = translatedText;

translation = string.Format(culture, translation, info.Args);
}
catch
{ }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be at least logged ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the old implementation it was ignored as well and just the old text used formattedText = translatedText;

}
catch
{
formattedText = translatedText;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be at least logged ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the old implementation it was ignored as well

}
catch
{
culture = CultureInfo.InvariantCulture;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be at least logged ?

Copy link
Contributor Author

@romanett romanett May 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the old implementation it was not. I think there a cases where it is okay that the locale is not known to the dotnet culture info, so it would spam the logging with unnecessary information

// else return the first available locale
else
{
KeyValuePair<string, string> defaultKVP = Translations.First();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add check if not empty since calling First() on empty Translations might throw exception.

Copy link
Contributor Author

@romanett romanett May 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

m_locale always has a value there so the dictionary is never empty

@romanett
Copy link
Contributor Author

I do not know exactly if {"t":[["en-US","Hello"],["de-DE","Hallo"]]} should be considered the same as {"t":[["de-DE","Hallo"],["en-US","Hello"]]}. Semantically I would say they represent the same translations. If this is true than LocalizedText.Equals and LocalizedText.GetHashCode methods should be changed to take this into account and operate on the translations not the string.

I disagree, the order of translations matters as it could represent the priority of the received translations for the client. so these two texts should not be considered eqal.

@mrsuciu
Copy link
Contributor

mrsuciu commented May 30, 2025

I do not know exactly if {"t":[["en-US","Hello"],["de-DE","Hallo"]]} should be considered the same as {"t":[["de-DE","Hallo"],["en-US","Hello"]]}. Semantically I would say they represent the same translations. If this is true than LocalizedText.Equals and LocalizedText.GetHashCode methods should be changed to take this into account and operate on the translations not the string.

I disagree, the order of translations matters as it could represent the priority of the received translations for the client. so these two texts should not be considered eqal.

I did not find a clear distinction criteria between two such localizedtext definitions in the spec other than the definition which indeed points to your conclusion since the locale and text pairs are put into an array (where order matters).

@romanett romanett requested a review from mrsuciu May 31, 2025 14:36
@mrsuciu mrsuciu merged commit 23a02fc into OPCFoundation:master Jun 5, 2025
77 checks passed
@romanett romanett deleted the LocalizedText branch August 4, 2025 14:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants