feat: adds localization to uui-pagination

[NguyenThuyLan]

Description

The uui-pagination element has no options for localization.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

I added 4 labels for 4 buttons (First, Previous, Next, Last) to generate their names.

How to test?

Screenshots (if appropriate)

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://delightful-beach-055ecb503-1069.westeurope.azurestaticapps.net

[iOvergaard]

Great so far. I see that we have hardcoded texts for "More pages" and "Current page: n" as well as "Go to page n". We need to localize those as well.

Maybe we could think of some way to group all of these, since it will be a lot of properties. How about using a record? Something like:

  @property({ type: Object })
  labels = {
    first: 'First',
    previous: 'Previous',
    next: 'Next',
    last: 'Last',
    current: 'Current page: {0}',
    goTo: 'Go to page {0}',
    showMore: 'More pages',
  };

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://delightful-beach-055ecb503-1069.westeurope.azurestaticapps.net

[iOvergaard]

Great so far. I see that we have hardcoded texts for "More pages" and "Current page: n" as well as "Go to page n". We need to localize those as well.

Maybe we could think of some way to group all of these, since it will be a lot of properties. How about using a record? Something like:

  @property({ type: Object })
  labels = {
    first: 'First',
    previous: 'Previous',
    next: 'Next',
    last: 'Last',
    current: 'Current page: {0}',
    goTo: 'Go to page {0}',
    showMore: 'More pages',
  };

I spoke with @nielslyngsoe, and we think it could make sense to introduce a factory function property to translate these things including variables. The profile of such a function could be:

@property({ attribute: false })
localize: (type: 'first' | 'last' | 'current' | 'xxx', ...args: unknown[]) => string = (type, ...args) => {
  switch(type) {
    case 'first':
      return 'First';
    case 'current':
      return 'Current page: ' + args[0];
  }
}

It would be its job to find a suiting translation for the type in question and could be called from the render() function directly:

render() {
  return html`<uui-button label=${this.localize('current', this.currentPage)></uui-button>`;
}

What do you think of that?

[nielslyngsoe]

Hi @NguyenThuyLan In the perspective of how we code-style wise have approached labels and messages previously I do have a different suggestion, which is building on top of the existing architecture where we have a property/attribute for each.
The style of what you have already done in this PR.

To support arguments for those labels, my suggestion is to enable the message properties to additionally accept a method. In this style:

firstLabel: string | () => string = 'First';

For one that accepts an argument it would look like this:

currentLabel: string | (current: number) => string = (n) => `Current page ${n}`;

So if you would like to bring your localization for this, it can look like this:

html`<uui-button .currentLabel=${(n) => this.localize('madeUpKeyForThisExample_currentPage', n)></uui-button>`;

In this way each label property can bring the relevant arguments for the use case, without poluting a general localization method.

And the implementor can to use strings for the labels where no arguments are needed:

html`
<uui-button
    firstLabel="First"
    .currentLabel=${(n) => this.localize('madeUpKeyForThisExample_currentPage', n)
    ></uui-button>
`;

This is important cause we have to remember the Backoffice is not the only usage of the UI Library. We have the Cloud Portal which only exists in English, so we should not make their life more complicated. And as well there are all the extensions, which again most extensions do not have localized labels.

I hope it makes sense, feel free to get in contact if you like to evaluate

Thanks

[nielslyngsoe]

Additional information regarding the implementation, regarding the addValidator from another PR:

Just wanted to make it available that the addvaidator implementation would look like this:

this.addValidator(
      'tooLong',
      () => {
        const label = this.maxlength;
        if (typeof label === 'function') {
            return label(this.maxlength, String(this.value).length);
        }
        return label;
      }
      () => !!this.maxlength && String(this.value).length > this.maxlength,
    );
    ```

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://delightful-beach-055ecb503-1069.westeurope.azurestaticapps.net

[nielslyngsoe]

If the label is a method then this will not work.

[nielslyngsoe]

I see I have caused some confusion here. Cause the general conversation around localization was from my side focusing on the ability to bring arguments to the labels. Looking at these specific four labels, then I only think it makes sense to accept a method when there is arguments to be considered for the label.

These four does not use any arguments as it stands right now. So I think they can just be of type string and then this is all fine :-)