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)?
Got it, makes sense!
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.
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.
We’re going to start some larger work on localization for our system. As a part of that work, we’ll also look at graphics.
Just wanted to check back on this one, to see if this is something that’s been discussed more internally?
(also, see my comment above about you being app-based, which makes it possible to run Sketch in CI, which is something Figma cannot compete with)
I’m afraid that support for localizations of exports via data or another mechanism is not a priority at the moment unfortunately.
When there are new developments on this topic, we’ll go back to this topic as soon as possible.