Skip to content

What is the recommended approach to translate labels, descriptions, etc? #739

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

Closed
2 tasks done
bjbrewster opened this issue Oct 25, 2017 · 17 comments
Closed
2 tasks done

Comments

@bjbrewster
Copy link

bjbrewster commented Oct 25, 2017

Prerequisites

  • I have read the documentation;
  • In the case of a bug report, I understand that providing a SSCCE example is tremendously useful to the maintainers.

Description

I am attempting to implement label/description/help translation using react-intl in a custom FieldTemplate and am trying to get the path to the current field. I can almost use the id property like id.split('_').slice(1) except field names may have _ as part of their name, and the root id name can change (uiSchema["ui:rootFieldId"]) and may contain _ also.

Is there some other way to get the path to the current property? If not, can I request the id field separator in utils toIdSchema() and ArrayField be changed to a double underscore __ similar to BEM notation. So 'myroot__foo_bar__0__qux'.split('__').slice(1) would yield ['foo_bar', '0', 'qux']? This also works for field names that begin with a single underscore as sometimes used to denote private or reserved field names like in CouchDB _id and _deleted.

Perhaps this approach is completely flawed when taking into account definitions etc. Another approach may be to recursively traverse the schema object and definitions separately, building up the path as I go, and add a title, description and help attribute to each object property.

How are others translating the labels, field titles, descriptions, help text etc?

Steps to Reproduce

N/A

Expected behavior

N/A

Actual behavior

N/A

Version

0.51.0

@bjbrewster bjbrewster changed the title How to get path of current property in custom FieldTemplate? What is the recommended approach to translate labels, descriptions, etc Oct 25, 2017
@bjbrewster bjbrewster changed the title What is the recommended approach to translate labels, descriptions, etc What is the recommended approach to translate labels, descriptions, etc? Oct 25, 2017
@glasserc
Copy link
Contributor

glasserc commented Nov 9, 2017

Hi, I'm not super familiar with react-intl, but I would have expected translating labels and things to happen at the schema layer, before it gets rendered. I wouldn't object to a PR adding a method to get the path to the current element. There's also an outstanding PR to parametrize the separator in #688, and if olzraiti's comments are addressed I would be willing to merge that too.

@ugogo
Copy link

ugogo commented Nov 10, 2017

On my side, I used a custom FieldTemplate

// FieldTemplate.jsx

const FormTemplate = ({ id, children, label, rawErrors, required, schema }) => {
...
return (
    <FormField errored={isErrored}>
      <FormLabel
        i18n={label}
        inputId={id}
        required={required}
      />

      { children }

      { !!rawErrors.length && (
        <FormErrors errors={rawErrors} />
      )}
    </FormField>
  );
// FormLabel.jsx
const FormLabel = ({ i18n, inputId, required }) => (
  <label htmlFor={inputId}>
    <FormattedMessage id={i18n} />
    { required ? '*' : null }
  </label>
);

Not sure this is the best way to do it because you have to rewrite some logic, but you'll have a full control on the displayed items, i18n included

@landsman
Copy link

landsman commented Dec 2, 2018

Is there some good solution please?

@bjbrewster
Copy link
Author

bjbrewster commented Dec 3, 2018

I originally tried adding custom widgets and field templates etc and had a dodgy function to get the property path and attempt look up the title, description and help text during render. Getting the property path is not really possible, especially when definitions are also used.

In the end, we wrote a intlSchema method to transform the json schema (returns new object, original schema is not touched) before passing to react-jsonschema-form, updating the title, description and help properties if found in the locale text. I'm using redux, so I used this method in the redux connector when passing the schema to my react component. I also use redux-intl so I was able to easily pass all the intl messages to my helper.

I hope this points you in the right direction. I'll post a Codepen example with my recursive method soon.

Cheers,
Brendan

@bjbrewster
Copy link
Author

Here is an example Codepen with my recursive intlSchema method.

https://codepen.io/bjbrewster/pen/xQeRKR

Cheers,
Brendan

@epicfaace
Copy link
Member

Closing this in favor of #1195.

@epicfaace
Copy link
Member

Sorry, I misread -- ajv-i18n is only for localizing errors, but this issue is about localizing labels, descriptions, etc. of the entire form. Reopening.

@epicfaace epicfaace reopened this Mar 16, 2019
@bjbrewster
Copy link
Author

lol, thanks for that. I was wondering how the other issue superseded this.

@epicfaace
Copy link
Member

@bjbrewster your solution looks good. Based on your work, do you think there might be a way to add this functionality into the core library react-jsonschema-form (or at least make it easier to integrate internationalization libraries)?

@BurkovBA
Copy link

BurkovBA commented Sep 9, 2019

This translations thing is a big issue.

Assumption that field value equals to field label is a poor design decision in general. For example, Angular forms have a clear distinction between field values and labels.

I'd suggest adding a separate prop for field labels and option labels.

Anyways, many thanks for a very helpful library.

@landsman
Copy link

After year I am handling with this issue again.
I have implemented LinguiJS but labels are crying that <Trans> macro is not string:

Warning: Failed prop type: Invalid prop `label` of type `object` supplied to `DefaultTemplate`, expected `string`.
    in DefaultTemplate (created by SchemaField)
    in SchemaField (created by ObjectField)
    in fieldset (created by DefaultObjectFieldTemplate)
    in DefaultObjectFieldTemplate (created by ObjectField)
    in ObjectField (created by SchemaField)
    in div (created by WrapIfAdditional)
    in WrapIfAdditional (created by DefaultTemplate)
    in DefaultTemplate (created by SchemaField)
    in SchemaField (created by Form)
    in form (created by Form)
    in Form (created by Context.Consumer)
    in div (created by Context.Consumer)
    in div (created by Context.Consumer)
    in div (created by Context.Consumer)
    in div (created by Layout)
    in div (created by Layout)
    in main (created by Layout)
    in div (created by Layout)
    in Layout (created by Event)
    in Event (created by _default)
    in I18nProvider (created by LangProvider)
    in LangProvider (created by _default)
    in _default
    in Suspense (created by AppContainer)
    in Container (created by AppContainer)
    in AppContainer

Please can you think to this in V2?
#1409

@epicfaace
Copy link
Member

@landsman

After year I am handling with this issue again.
I have implemented LinguiJS but labels are crying that <Trans> macro is not string:

This might be a separate issue -- and I've seen those warnings in the console before. Could you open a new issue with a minimal reproduction of the problem? That would help.

@hiitskiran
Copy link

hiitskiran commented Jun 9, 2020

this issue is still in open status, I haven't found any documentation or any sample given in live playground examples. Is there a recommended way to translate UI field labels as well as error messages?

@n3ps
Copy link

n3ps commented May 10, 2021

While waiting for a "recommended" approach, what are the drawbacks of adding a custom property (ie. translation key) in the schema and using that in a custom FieldTemplate component to lookup the translation?

@bjbrewster
Copy link
Author

You can definitely do that, its just a shame to duplicate the property names and paths when creating the translation key and also add translation keys for help and description fields if you need them.

@heath-freenome
Copy link
Member

@bjbrewster With the advent of the idSeparator property, you can now control whether to use the _ or some other delimiter. This should solve your problem. On a separate note, we are planning to provide the ability to localize the RJSF internal strings in the near future. Closing

@bjbrewster
Copy link
Author

@heath-freenome Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants