i18n

[leomp12]

We're still not dealing well with internationalization, and it's really important.

Some components have attributes in English, eg.: aria-label, title, alt, of course it's possible to replace it using slots, but I think it should be customizable without needing to rewrite markup, wdyt?

And does anyone have a suggestion? Using props, a configurable dictionary object?

┆Issue is synchronized with this Jira Zadanie by Unito

[filrak]

@leomp12 I'm not sure if i18n for attribute/prop names is something that we should consider. Have you seen any examples of libs doing such things?

[leomp12]

Hey @filrak , usually libraries don't handle aria-label, title and other attrs by default, when it does these attributes are editable by props. But we're setting a lot of these attributes (specially to handle a11y by default), and it's good but making it editable by props would flood components API. At the same time I consider it important to be able to change the string in these attributes, or at least change the language, so I thought about using an dictionary object. Do you understand my position? Wdyt?

[filrak]

Ah ok. I somehow misunderstood you... don;'t even want to tell in which way since it now seems embarassing 😆

Of course we should do this. we even have it on some components so it should be a convention

[filrak]

Could you list the tags that should be editable except alt and aria-label ? I'll make an issue then and try to find some devs in our company to do it

[leomp12]

I think is just alt and aria-label. Actually, I think the point is define convention to solve it, then we can go fixing the components one by one.

As example, we have this problem with SfBottomNavigation (alt of all icons) and SfPagination (prev and next aria-label).

[leomp12]

I mean, should we create a dictionary object or use props (imo would not be good) to handle it? Or another idea?

[filrak]

Dictionary object seems right if there is more than 1 element to label. Otherwise Imho we can safely use props like aria-label, alt? Wdyt? are two conventions to avoid weird structures ok for you or we should go consistantly with just one? @mayashavin you are A11y master, your opinion is valueable :)

[leomp12]

The point is that we're generally talking about child elements inside the components, for example on pagination component we have mocked strings on prev and next icons alt, so I don't think would be so good using props, but would solve the problem too...

About other Vue libraries, I've used Element UI once, they handle that with locale.use(lang), take a look here as example.

[filrak]

@leomp12 seems like the right choice except we don't utilize use method but I can see it as a handler like setLocale(locale). The problem is that we are hardcoding the context here so I'm still wondering if passing alts through probs isn't better. summoning @mayashavin and @przspa to hear other opinions too ;)

[EduardDopler]

By "dictionary object" do you mean a global file with default messages that the user can replace? Sounds good to me! This object can be imported in every component which presents text to the user. Something like:

_messages.js:

const messages = {
  en_US: {
    PREV: "previous",
    NEXT: "next",
    GO_TO_NEXT_PAGE: "go to next page"
  }
}

We deliver only the US-English messages but the user can customize the file by overriding it (like sfui.scss) and e.g. add more translations.

I guess we could import the file (our default or the user one) on-the-fly, right?

[leomp12]

@EduardDopler when I opened this issue I was thinking on this dictionary object, but now I think this approach is better (same functionality): https://github.com/ecomclub/i18n

With that we can also create plug and play translations without building unnecessary bundles :)

I think we should also have a method to set the current lang (eg.: setLocale) and another method to get the string for current lang (eg.: i18n('Hello')).