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

Localisation #255

Closed
ariskemper opened this issue May 14, 2014 · 9 comments
Closed

Localisation #255

ariskemper opened this issue May 14, 2014 · 9 comments
Labels

Comments

@ariskemper
Copy link
Member

Would be good that Loopback supports localisation for current models and messages in responses.

Example:

  • Change locale in headers or programmaticaly in user settings.

Proposed solution:

  • Integration of i18next-node library
@bajtos
Copy link
Member

bajtos commented May 14, 2014

Hi @ariskemper, could you please provide specific examples of what you would like to localize?

LoopBack uses Express under the hood, thus you can add i18next-node library to your LoopBack-based application in the same way you would add it to an Express app.

@ariskemper
Copy link
Member Author

Its mean as enhancement in Loopback, because messages in models are currently only in English.

@bajtos
Copy link
Member

bajtos commented May 15, 2014

because messages in models are currently only in English.

What kind of messages do you mean? Validation messages?

@ariskemper
Copy link
Member Author

Yes i mean validation messages.

@bajtos
Copy link
Member

bajtos commented May 19, 2014

Rather than modifying the error responses returned by the server, you can localise the error message on the client. The validation error response contains error codes in error.details.codes, which allows clients to map errors to any messages they want.

Here is an example error response:

 {
  "name": "ValidationError",
  "status": 422,
  "message": "The Model instance is not valid. \
 See `details` property of the error object for more info.",
  "statusCode": 422,
  "details": {
    "context": "user",
    "codes": {
      "password": [
        "presence"
      ],
      "email": [
        "uniqueness"
      ]
   },
    "messages": {
      "password": [
       "can't be blank"
     ],
      "email": [
        "Email already exists"
      ]
    }
  },
}

@crandmck
Copy link
Contributor

I added a note to http://docs.strongloop.com/display/LB/Validating+model+data. It's pretty minimal, so if you have have additional suggestions, please let me know.

@bajtos bajtos closed this as completed Aug 22, 2014
@bajtos
Copy link
Member

bajtos commented Aug 22, 2014

I have closed the issue. Feel free to reopen if you have more question.

@tohagan
Copy link

tohagan commented Oct 6, 2017

I read this documentation but was rather confused ...

Does that mean that for all places in the Validateable API where I can specify a message property I can also specify now use a code property? If so, its undocumented, If not, I think that what's needed.

Example:

      Model.validate('expires', function(err: Function) {
        let now = new Date();
        if (this.expires < now) return err();
      }, {message: 'expire value must be a future date', code: 'future'});

NOTE: In some cases a code property may be inadequate as in order to the build the localised error message client side, you may need to additional server side data from other records or server side logic so in an ideal universe, the code could become an error object containing the code + other data.

@bajtos
Copy link
Member

bajtos commented Feb 9, 2018

@tohagan IIRC, the code is set to the name of the validator as provided in the first argument of Model.validate. So in your example, the code will be set by LoopBack to expires.

NOTE: In some cases a code property may be inadequate as in order to the build the localised error message client side, you may need to additional server side data from other records or server side logic so in an ideal universe, the code could become an error object containing the code + other data.

I see your point. Could you please open a new GitHub issue to discuss this feature and keep track of it? It is rather off-topic here.

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

No branches or pull requests

4 participants