Would be great if the current data functionality could support localisations.
Basically, what we’d like to do is the following:
Design UI with English, but tag/name each text layer with a special key.
Link a JSON document containing translations for each key. These keys should override the “default/fallback” text specified in the document. If no JSON document is linked, the content is shown with english text. If a JSON document with french translations is linked, we show the french text.
To make this work, the current JSON data linking need to support a dict at the top level (only array is permitted today) and that dict should contain multiple keys and translation texts as values.
It should be possible to control/link different documents via the CLI. That way, we can automate translation generation, such that we iterate over a list of 5-10 language files, and generate unique exports SVGs for each locale.
Ideally an easy way to add a suffix to all exported images, via the CLI. So files are named after artboard/exportable, but with an additional suffix specified in the CLI. That way, we can pass an “-en”, “-fr” suffix etc.
(reason for not doing translations with search/replace inside the SVG file itself, is that it wouldn’t work with outlined text (if we want to convert to outline before exporting))
I can totally see the use for this feature, but I think I would argue against using Data for this. The feature was designed to provide essentially useful randomised data for quick mockups: user names, avatars, dates are the perfect example here. Including the plugin support that is also part of this, the entire system is designed along the lines of “Give me X (random) values from your data set” and building this on top of that feels problematic/wrong.
Just out of curiosity, are you looking to primarily export multiple localisations out of a single file, or do you also want to view/edit them in the Sketch as well (maybe to see if they fit and then adjust as needed)?
Mostly exporting, but viewing them would also be useful (as you mention, to make sure longer strings fit).
Most localization setups uses one file per language, e.g. en.yml. Something like that would be neat.
One problem we have with Sketch is localising assets in multiple languages. There are probably several approaches you could take, but one would be this:
We’d then use this both on a developer machine, by the designer when testing different languages. But likely also in CI (Github Actions has support for macOS runners), for automation around localisations. That way, our localisation providers would push new texts to us via an API, and we can run Sketch headlessly to auto-update all SVGs.
Your current CLI mode for Sketch is already pretty good in my opinion, and have most of the functionality we’d need here (bulk-exporting SVGs). Maybe some command line flag to configure a suffix for all files, based on the locale. E.g. my-graphics-de.svg.
As for the CLI support, it would be enough if we could pass one locale YAML-file for each invocation. We could then simply write a script that loops over all locales, and generates all the files.
This functionality isn’t something that Figma could compete with easily, since they are webbased.
So getting deeper into the file authoring workflow, with CLI, scripts, etc. could be a good edge against Figma.
Because translation support isn’t available inside Sketch, we have a workflow where we output SVGs in English, and then translate them outside Sketch, after they have been generated. They are machine-translated by parsing the XML/SVG and replacing the text snippets.
A problem with this approach is that text boxes in Sketch aren’t translated into equivalent boxes in SVGs. See attached examples.
I know I’ve already advocated for mechanisms to help with translation inside Sketch documents, to export multiple versions of an illustration, with different text. But this added context just shows that it also isn’t trivial to solve this outside Sketch, because of how the SVGs are generated.
I think translations inside Sketch is the better way to go though, because even if text boxes were exported correctly, there would still not be any support for text anchoring and alignment in the SVG (without additional work), but such properties are available in the authoring format, i.e. the Sketch document.
