You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to make a proposal for building I18n Support into TableView.
I counted for ~20 fixed strings in the project that need to be translated. That seems to be a small number. So, for me, solutions involving x:uid or some resx/resw mimic seemed to be a little overkill. Also, since TableView is meant to be a .nuget package this would force the developer (w-ahmad) responsible for delivering all possible translations.
I thought we could put that small burden onto the user of the component, so if s/he wants localization s/he should provide it.
What I finally came up with is a simple Dictionary for all the fixed strings, keyed by some unique key. We can then provide a default dictionary (with the original english strings) and let the the user define another dictionary (for the foreign language), if wanted.
Naturally all occurences of fixed strings in the project have to be made indirect, going through the dictionary.
Proof of concept:
Major translation efforts go into the ColumnHeaderFlowout and into the RowHeaderFlowout.
Here are screenshots of a translation into german:
Here is the uncompiled project that produced the screenshots. Use the .git to discover all changes to the current sources (as of 2025-01-27).
Central to the i18n stuff is the translationdictionary. Since Xaml doesn't like generics, we masquerade the Dictionary<string, string> into a derived class: TableViewStrings. That class also defines the Default Dict.
Excerpt of the default dict:
internal static TableViewStrings TableViewDefaultStrings { get; } = new()
{
// occurances in TableView-C-olumn-H-eader.cs, => key starts with CH...
{ "CHBlank", "(Blank)" }, // in .Filter(object? item) and .PrepareFilterItems(string? _filterText)
// TableViewColumnHeader.OptionsFlyoutViewModel.cs => CHO... (C-olumn-H-eader-O-ptions)
{ "CHOSrtAsc", "Sort Ascending" }, // label for SortAscendingCommand
{ "CHOSrtDes", "Sort Descending" }, // label for SortDescendingCommand
{ "CHOSrtClr", "Clear Sorting" }, // label for ClearSortingCommand
...
In the TableView.Properties, we define a new DP 'Strings' of Type TableViewStrings. For the default value we use that DefaultDict. Therefore if the user doesn't define the property, s/he'll have all the english strings by default.
Since the Dict is defined as a property of TableView, the instance of TableView must be available to access the dict.
Generally the access is of the form tableView.Strings["<key>"].
Fortunately a reference to the TableView is always available, except for the 2 Controls Date/Timepicker.
There we need to translate the initial request-strings 'pick a Date/Time'. These controls have no access to TableView. But we can use the provided PlaceHolder-DPs and find the translated string in the Date/TimeColumn class (that serve as a parent).
There are currently 2 Places, where Labels are directly defined in .xaml, like 'PlaceholderText="...". These occurences must be changed to bound props, such that we can set the values from code (with Mode=OneTime).
If there would be a need in the future to have access to the Dict w/o having access to the TableView instance, we could easily implement a static Servive to indirectly access TableView.
Conclusion
Simple and expandable, I'd like to hear your comments.
The text was updated successfully, but these errors were encountered:
Proposal
I'd like to make a proposal for building I18n Support into TableView.
I counted for ~20 fixed strings in the project that need to be translated. That seems to be a small number. So, for me, solutions involving
x:uid
or some resx/resw mimic seemed to be a little overkill. Also, sinceTableView
is meant to be a .nuget package this would force the developer (w-ahmad) responsible for delivering all possible translations.I thought we could put that small burden onto the user of the component, so if s/he wants localization s/he should provide it.
What I finally came up with is a simple Dictionary for all the fixed strings, keyed by some unique key. We can then provide a default dictionary (with the original english strings) and let the the user define another dictionary (for the foreign language), if wanted.
Naturally all occurences of fixed strings in the project have to be made indirect, going through the dictionary.
Proof of concept:
Major translation efforts go into the ColumnHeaderFlowout and into the RowHeaderFlowout.
Here are screenshots of a translation into german:
Here is the uncompiled project that produced the screenshots. Use the .git to discover all changes to the current sources (as of 2025-01-27).
TableViewTester-3(Translation).zip
Implementation Details
Central to the i18n stuff is the translationdictionary. Since Xaml doesn't like generics, we masquerade the Dictionary<string, string> into a derived class:
TableViewStrings
. That class also defines the Default Dict.Excerpt of the default dict:
In the
TableView.Properties
, we define a new DP'Strings'
of TypeTableViewStrings
. For the default value we use that DefaultDict. Therefore if the user doesn't define the property, s/he'll have all the english strings by default.Here's how the user provides localization:
then in any TableView instance:
Access from code to the dictionary
Since the Dict is defined as a property of TableView, the instance of TableView must be available to access the dict.
Generally the access is of the form
tableView.Strings["<key>"]
.Fortunately a reference to the TableView is always available, except for the 2 Controls Date/Timepicker.
There we need to translate the initial request-strings 'pick a Date/Time'. These controls have no access to TableView. But we can use the provided PlaceHolder-DPs and find the translated string in the Date/TimeColumn class (that serve as a parent).
There are currently 2 Places, where Labels are directly defined in .xaml, like 'PlaceholderText="...". These occurences must be changed to bound props, such that we can set the values from code (with Mode=OneTime).
If there would be a need in the future to have access to the Dict w/o having access to the TableView instance, we could easily implement a static Servive to indirectly access TableView.
Conclusion
Simple and expandable, I'd like to hear your comments.
The text was updated successfully, but these errors were encountered: