Figure out a different way to do form field localizations #55
Comments
|
After looking at this in practice, I think that just having a nested key structure should be enough. Rather than using a {
"en": {
"firstName": {
"label": "First name"
}
},
"es": {
"firstName": {
"label": "Nombre"
}
}
}...or just collapse them like so: {
"en": {
"firstName.label": "First name"
},
"es": {
"firstName.label": "Nombre"
}
}We could even nest the component keys another level, e.g. |
|
Just for kicks, here is the output of |
|
We also have the ability to add arbitrary custom properties to any component (field):
These are simple key/value pairs, and it looks like the values are treated as strings in the UI, but this might be the place where we can either associate its label, description, etc. with localized string IDs; or we could even store the localizations right in there. One way this could work is that each of the field definitions in our "form library" would have a default set of custom properties attached whenever you pull it into your form in form.io:
So our common "Name" field could come with everything baked into it as custom properties: {
"customProperties": {
"es.label": "Nombre",
"zh.label": "姓名",
"tl.label": "Pangalan",
"i18n.namespace": "fullName"
}
}We would need to support this at the template level by looking up localized strings in the following order (e.g. for the input label):
In order for this to be clearer when editing on form.io, we could run custom JS on the portal that:
|
|
For now, I'm holding off on storing custom properties in each component instance and instead linking them together with unique string ids that are expected to match up between an API that generates JSON (for uploading to Phrase) and the template |
|
This is basically done in #106, which introduced the Lines 27 to 35 in 54d009e ...which means that in our templates we can use |
|
There are now lots of different ways to do this:
|
We currently have a kind of funky way of overriding field label and description localizations. The trick is to set the string ID column in your spreadsheet to
{key}_{property}, where{key}is the API key of the field you're targeting and{property}is the "part" of the field you're localizing: usuallylabelordescription, but sometimescontentfor HTML element components. There are some issues with this approach:This hack overrides the label, description (etc.) of the field as written on form.io, which can lead to some confusion if people start editing the fields on form.io and see no change in the rendered form. It's often much easier to edit the spreadsheet than the form definition itself, but there's no feedback on form.io to let people know that those labels, descriptions, or content will be overridden on sf.gov.
Because formiojs doesn't support i18next's ability to take an array of keys and treat the ones later in the list as fallbacks (
i18next.t(['confirm.yes', 'yes'])returnsyes, butform.t(['confirm.yes', 'yes'])returnsconfirm.yes,yesbecause it stringifies the array!), I've had to monkey-patch formio'st()implementation to do the Right Thing. This is... not ideal, and actually kind of a dangerous.I'm not sure what the right way is to do this, but namespaces might help. Either way, it would be good to get formiojs working with fallback key arrays so that we don't have to maintain this ugly patch.
Context might also be useful. Ambiguous strings like "feet" (used as a field suffix) would benefit from context when translating, and (if passed in all of the template calls 😬 ) even help us identify where certain strings are being used.
The text was updated successfully, but these errors were encountered: