You might be thinking, Are you crazy? What a headache! Tell the client to forget it and make a WordPress site if they want l10n.

You would have a point. WordPress is much more l10n-friendly than Wix, which had no user-friendly way to translate your website until very recently. However, I’m here to tell you that it is possible, and you don’t have to be a programmer to do it, but you will have to be willing to compromise on your fancy widgets and apps.

About Wix

Wix is a powerful website creation tool that allows you to make aesthetically stunning websites with no coding experience needed. It is extremely customizable, and you can drag and drop elements of the site into the exact places you want them. You can upload new fonts to your site, change colors, add images, link pages, and do pretty much anything by simply double clicking and changing the settings of a particular element. It takes very little time to create something beautiful, which has made it a very popular tool, especially among photographers.

Being one of those photographers who wanted to make a simple, attractive website for her photography, I made a Wix site for my photography company Butterflies & Daffodils a couple of years ago with no intention of ever localizing it. Frankly, I had almost no coding experience and no idea what l10n was, and I hadn’t started my M.A. in Translation at MIIS yet either. I put it together in a matter of hours one evening and have been very happy with its appearance ever since.

My happiness with the website was dampened a bit (but only a bit) when my colleagues and I decided to use it for our Website L10n project. It was daunting when I first started looking into the elements of my site and realized that some of it was untranslatable. However, the new Wix Multilingual feature makes translation a breeze for main content of the site, and we found some useful workarounds for the rest of it.

Ready to find out what we did? Here we go!

Step 1: Enable Wix Multilingual.

Enabling this feature on your site will allow you to add languages, make them visible/invisible, and translate directly on your website.

Step 2: Prep the site for l10n.

This basically means you’ll need to go through the site double-clicking everything to figure out what is translatable and what isn’t. If something isn’t, see if there is a way to universalize it to avoid the need for translation. For example, the text in Right Click Protect (an app that, as the name suggests, protects your website from right clicks) is not translatable. The good news is that you get to decide what it says, so instead of going with the standard “© Copyright Vanessa Curless” that it suggested, we took out the word “Copyright” and left the © because the symbol is much more universally understood than the English word.

Unfortunately, there are some cases where this is not such a simple fix. Currently, no apps and very few widgets are translatable. This meant that we had to recreate my Services page without using the Booking Services widget. Thankfully, my website is not very complicated, and I was not married to the idea of the widget, so this was the biggest change in the website that we had to make. If the website were more complex, or if I were a professional photographer depending on the Bookings widget to help me make a living, I would have been in more trouble.

Here are a couple of screenshots from the new Services page (which I have to say I am very happy with):

Step 3: Add your contributors.

This is one part of Wix l10n that is definitely not in its favor. In order to add your translators as contributors, you need to give them admin permissions. This gives them pretty much the same permissions as you, so they are able to edit anything on your website. I would really only recommend this if you fully trust your translators, and, thankfully, you can toggle off the publishing permissions so that you can at least review their work before it is out there for the world to see.

If you don’t do this, your only other option is to copy and paste all the text from your website (since there’s no “export content” function… so that’s a pain) and put it in a file to send to your translator. I’d suggest finding a translator you trust with admin permissions so you can avoid that headache.

Step 4: Get translating.

You literally double-click, and it gives you the option to translate.

This is a really nice feature because it allows you to see exactly how the translation will look on the site and if you need to change font or sizing. Keep in mind that if you change the font size or style in the menu or on a button, it will change it for all languages (also a bummer). Finding a font that worked for all of our languages (English, Spanish, French, Italian, Greek, Russian, and Chinese) was definitely a challenge. The most acceptable one that fit the website’s aesthetic was Dancing Script, but it definitely defaults to some other font for non-Latin languages that is less than ideal but at least acceptable (please excuse our non-Latin languages… these are machine translations and only used for the purpose of this project):

Step 5: Editing, proofreading, and QA

As I mentioned in Step 3, if you don’t give your translators publishing permissions, you can check to see how everything looks before the translations are visible to the public. Make sure you check to make sure that nothing is truncated and it all looks nice and tidy before publishing.

Truncation is super easy to fix, since you can just drag the button edges to make the translation fit:

Step 6: Make visible and publish!

When you’re sure your translations look the way you want and you’re ready for the world to see that language on the site, go ahead and make the language visible in the Multilingual Dashboard from Step 1. Go to your site to preview it and see how your new clientele will see the site in their language!

So… Is it worth the hassle?

There is a bit of hassle involved with localizing a Wix website, and, to answer this question, it really depends on how complex the website is. Because my photography website is so simple with just six pages, localizing it was not an impossible undertaking. I also didn’t use a ton of apps and widgets to begin with, so our workarounds didn’t take us days to complete. Also, there is really no way to change the coding because Wix is so protective of their beautiful graphics (which is understandable, to an extent), so you can’t even fix the untranslatable aspects through the back end if you are familiar with coding. Everything you change will mostly have to be done from the front end because the “Developer Tools” are kind of useless.

If you are planning on making a website and want all that beautiful Wix Code (JavaScript) built into it without having to create all that on your own, it’s a great website platform and allows you a lot of freedom, and, if you go into your website creation with l10n already in mind, it will be much easier for you to localize the site in the long run. BUT, if you have a complicated website with lots of apps and widgets you’re not willing to get rid of, you’ll have to decide if you want a Wix website or a localized website; you probably won’t be able to have it both ways.

I hope this was helpful to you! Let me know what you think in the comments below.

What’s Twine?

When working on the engineering for a l10n project, the simpler the workflow, the better. That’s why my colleagues and I got excited when we discovered Twine, a command line tool for centrally managing translated strings for apps that are available on both Android and iOS platforms.

Our Project

The Test Subject

We decided we wanted to figure out how Twine worked, so we had to find an open source app to use as an example. That’s when we found Wire, which was perfect because

1. it’s internationalized
2. it’s available on Android and iOS
3. its translated strings are not (yet) centrally managed
4. the coding uses string keys for both Android and iOS (even though this practice is more common for Android; if it hadn’t used a keyword system for the strings for iOS, we would have had to redo the coding or find another open source app to test on).

Wire uses crowdsourced translations for its strings, which go through a translation and editing process before being accepted. We noticed that their CrowdIn page had separate sections for their web/desktop app, Android, and iOS, which meant that the strings were not being centrally managed, and they could potentially even be translated by different translators. Because Wire’s user interface is almost identical for Android and iOS, it only makes sense for its strings to only be translated once and to be centrally managed.

The Workflow

Our workflow was a little modified for our pilot project, but the following graphic gives an overview of the Twine process:

The instructions provided on GitHub for installing and using Twine are iffy (and sometimes incorrect), so it took some trial and error for us to figure out how to use it. Here’s what we found worked best (follow along using the Twine instructions on GitHub:

1. Install Twine from the source. We were unable to install it as a gem because it claimed we had a missing directory (which was not missing, so we don’t really know what happened there).
2. Create your first Twine data file. Then, validate it. We didn’t run into any issues with this step.
3. Generate the PO source file to send to the translators using this command:
   $ twine generate-localization-archive twine.txt LocDrop1.zip -f gettext
   – Consume the localization file with this command:
   $ twine consume-localization-archive twine.txt LocDrop1_translated.zip –format gettext
   Note: For the purposes of this project, we used the crowdsourced translations from Wire’s CrowdIn page, aligned them with the source, made a TM, and translated using the TM and machine translation on Memsource.
4. Push the translations into the Twine data file. After doing this, make sure the language codes are correct at the tops of the files.
   – For iOS, that looked like this: $ twine generate-all-localization-files twine.txt wire-ios-develop/Wire-iOS/Resources/
   – For Android, the instructions were totally wrong on GitHub. The command should look something like this: $ twine generate-all-localization-files twine.txt wire-android-master/app/src/main/res
5. Your localized files will be generated for iOS and Android!

And there you have it! You should have your localized files for the iOS and Android platforms of your app!

A note on XCode…

The files seemed great from looking at them, but we wanted to test out the localized content in a simulator. My main role in the project was working on making the iOS app run, which ended up being a huge headache.

Since the app was already localized before for 10+ languages, and we unlocalized it for our project, I needed to reincorporate our project’s languages (French and Russian) back into the app. First, I had to find where those files needed to go. After getting everything figured out and finally ready for the simulator, I accidentally deleted something that I couldn’t undo (still unsure of what it was) and it ruined all my hard work, so I had to start over at about 1am. Anyway, after going through it again, here was the smoother process:

1. Make sure you have all the dependencies you need on your computer. I ended up needing to download Carthage for Wire using Terminal. This took some time to figure out and to download.
2. Because Wire had been localized already, we had a nice template to begin with. I was able to look at the file structure that they had used before and make sure that I put all the translated strings files and other l10n files where they needed to go. For example, there needed to be language folders in the Wire-iOS>Resources folder (with InfoPlist.strings, Localizable.strings, and Localizable.stringsdict) and Wire-iOS Share Extension (with only the Localizable.strings file).
3. Open the project in XCode. Make sure it builds to begin with.
4. Find all the files with localization data in them. There were three sections in the Wire project that had them, which I honestly discovered through trial and error and XCode telling me where my errors were. Uncheck any boxes that are not relevant to your project; otherwise, it will not build if it does not have the data for those languages. And, of course, make sure your folders and files all use the same language code as the options you have chosen in XCode (either with or without the country code).
   
5. Build the app and test it out in the simulator! Here are some screenshots from our localized app:
   

The Verdict

In conclusion, Twine is definitely a worthwhile tool to learn. Once you get the process down, it is not too complicated and would be a huge timesaver for companies who wish to localize an app available for both Android and iOS. For our test app, Wire, it would definitely be a worthwhile decision for them to start using this program, especially given the almost identical UIs.

I hope this has been helpful! Comment below if you have any questions, and I’ll try to answer to the best of my knowledge.