Closed bebraw closed 9 years ago
I think this is where the face that schemas are pure data really shines. We can keep the translation completely outside of plexus-form
and just feed it a schema that's been pre-translated into the desired language.
Assuming at first that it is okay to include the schema in the JS code, here's what this might look like. Say we have the following definitions:
var i18n = {
en: {
form_title : "Example form",
form_description: "A form based on a schema",
name_title : "Your name",
name_description: "Your full name",
age_title : "Your age"
},
de: {
form_title : "Beispielformular",
form_description: "Ein Formular basierend auf einem Schema",
name_title : "Ihr Name",
name_description: "Ihr vollständiger Name",
age_title : "Ihr Alter"
}
};
var language = 'en';
var strings = i18n[language];
Then we could define a schema thus:
var schema = {
title: strings.form_title,
description: strings.form_description,
type: "object",
properties: {
name: {
title: strings.name_title,
description: strings.name_description,
type: "string"
},
age: {
title: strings.age_title,
type: "integer"
}
}
};
The i18n
object can of course be constructed at runtime based on a collection of configuration files, and the language
variable can be set depending on location or user preferences. If the schema is to be read from a configuration file, as well, we'll have to use special strings for values to be translated and run a recursive translation function through the data. So basically we'll have something like a schema template, but without all the parsing and string mangling.
Something that is not being translated in this example are of course the error messages produced by plexus-validate
, which are currently not customisable.
This approach makes a lot of sense. Thanks.
The implicit approach I suggested might work with this scheme as well. In that case you'll need to pass schema through a transformer that performs the mapping (ie. translate(schema, i18n[language])
-> translated schema). Then if you change the language you hit the transformer again.
I need to play around with this to see if I can get it to work nicely.
It's clear how to deal with this now so I guess it's safe to close the issue. Especially now that it's possible to set enumNames
. There could be some bits that are not possible to translate yet but if I bump into those, I'll make separate PRs.
It would be useful if it was possible to translate schema
titles
anddescriptions
somehow. Given schemas give translation keys implicitly (ie.age.title
orcolor.properties.hasFave.title
at demo), maybe it would be possible to build on that? I wonder how this would work with enums, though. Besides this sort of mapping you would need to provide means to perform actual translation (extra hook).