Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localization #205

Closed
olzraiti opened this issue May 17, 2016 · 7 comments
Closed

Localization #205

olzraiti opened this issue May 17, 2016 · 7 comments

Comments

@olzraiti
Copy link
Contributor

olzraiti commented May 17, 2016

Currently there is no way to localize the form (add/remove/submit -buttons, error messages).
Localizations could be in a separate schema (example below). This would allow uniform localization technique for fields provided by the form and also custom schema fields. However, this wouldn't provide a way to localize error messages. Maybe a error message formatter function could be given to the form as a parameter.

jsonSchema:

{type: "object",
 properties: {
     custom: {
         type: "object",
         properties: { ... }
     },
     array: {
          type: "array",
          items: { ... }
      }
 }
}

uiSchema:

{
 custom: {
     "ui:field": someField
 }
}

localizationschema:

{
    array: {
        add: "localized add text",
        delete: "localized delete text"
    }, custom: {
        { ... }
    }
}
@vixriihi
Copy link

vixriihi commented Jun 8, 2016

Or could we add dependency to something like https://github.com/yahoo/react-intl and pass in the translations in the form properties?

@olzraiti
Copy link
Contributor Author

After #285 is merged, the only thing that can't be localized are the jsonschema validations.

The jsonschema validations can be localized by inspecting the ValidationError object that jsonschema.validate() returns (see: tdegrunt/jsonschema#147). In order to allow this lib's users to localize the jsonschema validations, it should be either possible to disable jsonschema validating so the users can do the validation themself, or provide a validation interceptor that would receive the ValidationError object that jsonschema returns.

@olzraiti
Copy link
Contributor Author

@n1k0 : Would you accept a pull request if I wrote one? I'd like to have some feedback about my previous message, if I start working on this. :-)

@n1k0
Copy link
Collaborator

n1k0 commented Aug 29, 2016

@olzraiti sure, let's just polish and land #285 first, see my latest comments on the PR :)

@DimitryDushkin
Copy link

i18n is quite important. I think react-intl integration would be the simplest.

@olzraiti
Copy link
Contributor Author

Closed by #432

@afeld
Copy link

afeld commented Jul 18, 2018

cc #739

heath-freenome added a commit to heath-freenome/react-jsonschema-form that referenced this issue Feb 27, 2023
True fix for rjsf-team#205 to support localizing the internal strings in @rjsf
- In `@rjsf/utils`, added `TranslatableString` enum and `englishStringTranslator()` and `replaceStringParameters()` to support localization
  - Also updated the `Registry` type to add the `translateString` function
  - Added 100% unit testing for the new functions
- In `@rjsf/core`, added a new `translateString` prop to `FormProps` as well as using that prop in the `registry` if provided
  - Updated the `getDefaultRegistry()` to set `translateString` to `englishStringTranslator`
  - Updated `ArrayField`, `BooleanField`, `MultiSchemaField`, `ObjectField`, `SchemaField`, `AddButton`, `IconButton`s, `ErrorList`, `WrapIfAdditionalTemplate` and `AltDateWidget` and `FileWidget` to use `translateString`
  - Added the `markdown-to-jsx` to support localizing the `UnsupportedField`
- In all the themes, updated `ErrorList`, `IconButton`s, `AddButton`, `WrapIfAdditionalTemplate` and where applicable `AltDateWidget` to use `translateString` from the registry
  - Updated the snapshots for `UnsupportedField` based on the cleaned up translation formatting
- In `@rjsf/chakra-ui`, updated `TextAreaWidget` and `UpDownWidget` to switch `??` syntax to `||`
- In `@rjsf/semantic-ui`, updated the `FieldErrorTemplate` and `FieldHelpTemplate` to use the `errorId()` and `helpId()` functions
- Updated the `utility-functions` docs for the enums and the new functions
- Updated the `form-props` docs to describe the new `translateString` prop
- Updated the `CHANGELOG` accordingly
heath-freenome added a commit to heath-freenome/react-jsonschema-form that referenced this issue Feb 27, 2023
True fix for rjsf-team#205 to support localizing the internal strings in @rjsf
- In `@rjsf/utils`, added `TranslatableString` enum and `englishStringTranslator()` and `replaceStringParameters()` to support localization
  - Also updated the `Registry` type to add the `translateString` function
  - Added 100% unit testing for the new functions
- In `@rjsf/core`, added a new `translateString` prop to `FormProps` as well as using that prop in the `registry` if provided
  - Updated the `getDefaultRegistry()` to set `translateString` to `englishStringTranslator`
  - Updated `ArrayField`, `BooleanField`, `MultiSchemaField`, `ObjectField`, `SchemaField`, `AddButton`, `IconButton`s, `ErrorList`, `WrapIfAdditionalTemplate` and `AltDateWidget` and `FileWidget` to use `translateString`
  - Added the `markdown-to-jsx` to support localizing the `UnsupportedField`
- In all the themes, updated `ErrorList`, `IconButton`s, `AddButton`, `WrapIfAdditionalTemplate` and where applicable `AltDateWidget` to use `translateString` from the registry
  - Updated the snapshots for `UnsupportedField` based on the cleaned up translation formatting
- In `@rjsf/chakra-ui`, updated `TextAreaWidget` and `UpDownWidget` to switch `??` syntax to `||`
- In `@rjsf/semantic-ui`, updated the `FieldErrorTemplate` and `FieldHelpTemplate` to use the `errorId()` and `helpId()` functions
- Updated the `utility-functions` docs for the enums and the new functions
- Updated the `form-props` docs to describe the new `translateString` prop
- Updated the `CHANGELOG` accordingly
heath-freenome added a commit that referenced this issue Mar 2, 2023
* feature: Added the ability to localize RJSF internal strings

True fix for #205 to support localizing the internal strings in @rjsf
- In `@rjsf/utils`, added `TranslatableString` enum and `englishStringTranslator()` and `replaceStringParameters()` to support localization
  - Also updated the `Registry` type to add the `translateString` function
  - Added 100% unit testing for the new functions
- In `@rjsf/core`, added a new `translateString` prop to `FormProps` as well as using that prop in the `registry` if provided
  - Updated the `getDefaultRegistry()` to set `translateString` to `englishStringTranslator`
  - Updated `ArrayField`, `BooleanField`, `MultiSchemaField`, `ObjectField`, `SchemaField`, `AddButton`, `IconButton`s, `ErrorList`, `WrapIfAdditionalTemplate` and `AltDateWidget` and `FileWidget` to use `translateString`
  - Added the `markdown-to-jsx` to support localizing the `UnsupportedField`
- In all the themes, updated `ErrorList`, `IconButton`s, `AddButton`, `WrapIfAdditionalTemplate` and where applicable `AltDateWidget` to use `translateString` from the registry
  - Updated the snapshots for `UnsupportedField` based on the cleaned up translation formatting
- In `@rjsf/chakra-ui`, updated `TextAreaWidget` and `UpDownWidget` to switch `??` syntax to `||`
- In `@rjsf/semantic-ui`, updated the `FieldErrorTemplate` and `FieldHelpTemplate` to use the `errorId()` and `helpId()` functions
- Updated the `utility-functions` docs for the enums and the new functions
- Updated the `form-props` docs to describe the new `translateString` prop
- Updated the `CHANGELOG` accordingly

* Update packages/chakra-ui/src/UpDownWidget/UpDownWidget.tsx

* Apply suggestions from code review

Documented support for markdown and html as well

* Apply suggestions from code review

Minor fixes

* Apply suggestions from code review

small doc fix

* Apply suggestions from code review

More documentation updates

* Apply suggestions from code review

Revert change
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

No branches or pull requests

5 participants