iTwin
Future: Scoped sizing using Context
Add the ability to set size on the entire page & all components match. Unsure if this will be a breaking change or not.
It might be useful to display elements in a container component consistently. I.e. a toolbar component defines the size, every toolbar item is rendered with the same size.
From our iTwinUI community meeting:
localize “Loading.” text in progress indicator
@veekeys
From our iTwinUI community meeting:
localize “Loading.” text in progress indicator
@veekeys
Probably not only in progress indicator. Can review all the "visually hidden" strings throughout the components. Next stage would be thinking if extracting all localisable strings into single place would make sense? (I am not sure yet about this one, especially how this would be setup in multiple packages using iTwinUI)
I had one more thought on this.. Actually, if there are strings which should be just localised (same word kept, just different language), those should be localised in iTwinUI itself. That way it could be handled from centralised place rather than each product localising same string all over again. I am not sure now if there are strings in iTwinUI, which could be changed? Datepicker: for sure only localisation Loading: I guess also just localisation? Close icons: Localisation
Need to review cases with hardcoded strings. That would mean adding some library (react-i18next) and then preparing the library for localisation (moving strings to separate file). And then in case there is any product requiring some language, iTwinUI would need to work with localisation team on this (probably some integration of process in github might be a challenge... )
That would mean adding some library (react-i18next) and then preparing the library for localisation (moving strings to separate file). And then in case there is any product requiring some language, iTwinUI would need to work with localisation team on this (probably some integration of process in github might be a challenge... )
Is there a defacto library that is used across all applications?
I don't think we should add a dependency on a specific i18n library. The design system should be compatible with whatever library the application prefers to use. If we add a dependency on one i18n library and the application uses another, it could technically still work but would cause unnecessary duplication in the client JS bundle.
