How to Localize a Wix Site

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.

Using Twine for Centralized Management of Translated Strings

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 -f gettext
    – Consume the localization file with this command:
    $ twine consume-localization-archive twine.txt –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.

Photoshop Transcreation à la Kellogg’s


Companies often recycle advertisement styles depending on where an ad is being used and for what audience. After all, if you come up with a good design, why throw it out and create a new one if you could just tweak it? This process is known as “transcreation.”

This project started off as a transcreation proof of concept created by a fellow Translation student and me. We found a JPG of a Kellogg’s ad that was used in Venezuela during the Copa América soccer championship, which took place in Chile in 2015.

This ad features the stadium where the championship was held as well as the Latin American versions of all the logos (and, of course, the logo pertaining to that year’s Copa América). The stars at the top middle are from the Venezuelan flag, and the blue and red foreground represents Chile’s national colors. The cereal boxes feature Kellogg’s characters wearing Argentinian and Chilean soccer jerseys (the two participants in the final round of the championship), and they are holding Copa América trophies. The main text literally translates to “Your passion starts with a good breakfast.” As you can see, there is Spanish all over the place and plenty of little details to localize.

Research Phase

We started off researching for what sort of event Kellogg’s may want to transcreate this ad. We landed on the Super Bowl because of Kellogg’s’ sponsorship of many sporting events, such as:

  • Copa América
  • Major League Soccer
  • US Olympic and Paralympic Teams
  • American Major League Baseball
  • Canadian National Hockey League
  • Australian National Women’s Football League

Because Kellogg’s had a commercial in Super Bowl LII, we thought they would likely want to have ads for the next Super Bowl as well, so we decided to use the teams from this year’s Super Bowl as an example for what next year’s print ad could look like.


We spotted some potential problems for transcreating this ad right away and came up with the following solutions:

  • National pride will need to change to team pride.
  • Americans do not usually talk about their “passion” for a specific team, so we’ll need a similar but not literal translation for a US audience (We ultimately came up with “Start your Sunday morning with a Super Bowl of cereal.”).
  • Copa América 2015 logo will need to change to the Super Bowl LII logo.
  • Venezuelan stars will be changed to team logos (Patriots and Eagles).
  • Background color will be changed to team colors.
  • Images, graphics, names of cereals, Twitter accounts, and web address will need to be localized.

So, with that, the concept was ready, and it was time to start creating!


Getting Started

While the concept was made with a Translation classmate, the Photoshop work was 100% up to me (because that’s what happens when only one of you is specializing in Localization Management). Taking into account all our ideas, I started off by getting my assets:

  • Stock photos of: storm clouds, American football yard lines, and the US Bank Stadium
  • Transparent logos
  • Similar fonts
  • American Kellogg’s Twitter accounts and website
  • Transparent trophy
  • Cut out cereal boxes and pouring cereal, separately, from original ad

Then, I tried to keep a similar composition to the original ad and placed the pieces where they needed to go. After much snipping and tweaking, they ended up where I wanted them. I decided to keep the cereal boxes and the falling cereal as separate layers so I would have more flexibility regarding where the cereal would end up in relation to the stadium. I then changed the colors of the characters’ jerseys using the paintbrush tool and the “hue” layer overlay option, switched out the trophies (and filled in some background color), and changed the logos on the boxes.

Next came the colored overlay. I took some creative license and made the colors be on the opposite sides of their corresponding team logos so that it wouldn’t be totally dark blue on one side and totally teal on the other. I added all the translations and localized logos, Twitter accounts, and website, and voilà:

The low resolution is thanks to my brilliant idea to keep my PSD about the same size as the original JPG. Later on, this did not fly with my perfectionism.

Detail Work

To get the stadium to be a similar style and texture as the original took a great deal of effort and many more hours than I expected. In the end, I ended up doing the following:

  • changed the layer to black-and-white
  • heightened the contrast and brightness of the layer
  • duplicated the layer and applied a rough texture
  • lowered the opacity of the duplicated layer to 35%
  • made a color-range selection of all light gray to white parts of the image
  • painstakingly edited the details of the selection until it was exactly how I wanted it
  • made sure to leave color where there would be shadows to make the stadium more three-dimensional (see original ad)
  • switched to the color layer
  • erased the contents of the selection from the color layer to reveal the white underneath
  • continued to erase parts of the colored layer until I was happy with the result

The final touch to the project was adding “Official Cereal” to the cereal boxes, which is written on a curve via the “Warp Text…” option. I then rasterized the text and played with the size until it was about the same resolution as the cereal boxes.

Resolution Problems

After staring at this image for awhile and realizing I would be sharing it on a huge screen in front of an auditorium of people, I started to rethink the low resolution and image size.

Since there was nothing I could do about the quality of the cereal boxes and the stock photo of the stadium, I decided to leave the background a lower resolution and heighten the resolution of the foreground. This was when I realized, I HAD FORGOTTEN TO SAVE MY ASSETS TO MY COMPUTER. I had, instead, merely copied the images from my internet sources. Cue: smoke coming out of my ears.

After a process of re-Google image searching the logos, I was able to double the image size in Photoshop and re-add the higher-quality logos. Once I finished tweaking a couple more pixel-sized details, boom:

The masterpiece was complete.

XTRF for Dummies

Why It’s Worth Learning

Trust me, I mean dummy in the nicest sense of the word.

As an English-Spanish Translation and Interpretation MA student trying to figure out the world of localization management, I certainly consider myself an XTRF dummy (and a Translation Localization Management dummy in general). That said, my hope is that this blog will help you understand a bit more about XTRF as a useful tool in your pursuit of localization management happiness.

I am currently in my first semester as a MA student at MIIS, and I have only had three classes on XTRF and how it works. So, I am about as new to XTRF as it gets, while still knowing a little bit about how it works. Hopefully this will be of use to you as an XTRF newbie/dummy as well so you can see the benefits of using this program.

In this article, I’m going to be covering three main topics for why I strongly believe that XTRF is worth learning for anyone who in interested/involved in the TLM industry:

  1. It’s specifically made for the TLM market. This is unusual.
  2. It is mostly user-friendly.
  3. It keeps files all in one place.

These reasons may seem a bit shallow at first, but let me give you a brief explanation of why I find these aspects important for a TLM tool:


It’s Specifically Made for the TLM Market.

I’m not bluffing when I say this is unusual. The other tools that I have worked with, such as Basecamp and ProjectLibre, are not made for the TLM market. This does not make them bad tools by any means; however, it does mean that they do not have all the capabilities you’ll need as someone involved in the translation/localization process.

Basecamp is a simple tool if you really like making lists. You can manually put in project roles, due dates, etc., but nothing is specific to TLM. It is rather time-consuming and, in my opinion, is not worth the time if you are using it for something as specific as TLM.

ProjectLibre could still be of use to someone who truly enjoys seeing a project mapped out. It could, in fact, be nice for your client to see your work-flow in such a visual way (if you are comfortable with sharing that sort of information with your client). However, if you do not need such a visual, XTRF can easily get the job done without the need for an extra program.

So, I have a few questions for you that you may not have thought about:

  • Did you ever think you’d need a specific button for choosing who you’d like to do the translation, editing, or proofreading of a project? That option actually exists on the XTRF program.
  • Want to set specific rates for a translation? There’s an app (or program, rather) for that: XTRF.
  • Do you need to know when your vendors are taking vacations? That’s available too.

Vendor vacations

These are things that I had honestly not really thought much about before I began using XTRF; however, they are quite important in order to make the TEP process run smoothly. In my opinion, it is not worth the hassle to try to use separate programs with generic capabilities when there is one specialized program available (XTRF) that does just about everything you might need.


It Is Mostly User-Friendly

There is no need to be bogged down by a tool. In fact, a tool should do the opposite: make your life easier. Once you learn the basics of XTRF, it is an extremely customizable tool, allowing you, your vendors, and your clients to all use the same platform for easy access.

Something to keep in mind when you are using a tool that you want others to also use is that it needs to not be a waste of time for anyone involved. Want your vendors to use a certain tool? Don’t make them use up a great deal of their precious, unpaid time to do so (that is, if you want them to do more TEP for you in the future). Want your clients to use a certain tool? Don’t scare them away with something complicated.

The interface of XTRF looks nice and clean, it is fairly easy to find what you are looking for with a few clicks, and there is are distinct interfaces for administrators, vendors, and clients. The client interface is probably the cleanest and easiest to navigate (which certainly looks good for business), and the vendor interface is pretty self-explanatory as well.

Client interface

For the administrative side, you will have to do a bit more digging to find what you need in the nooks and crannies of the program. That said, the learning curve is certainly going to be worth it in the long run.


It Keeps Files All in One Place

Even if you are a naturally organized person, it is likely that you have lost a file at some point in your life. You searched your computer for every possible name that file could have, but it was somehow lost in the abyss of TLM files.

Well, you can kiss that problem goodbye, at least for your TLM files (I can’t guarantee whether or not you’ll find that #throwbackthursday photo from ten years ago that you’re dying to post). With XTRF, all files in the translation process are uploaded to the program itself. The entire program would have to crash and never come back for those files to be lost, which is much less likely to happen than your losing a file (knock on wood).

In fact, files are sent from one person to the other through the program. The client uploads the files, the translator translates, the editor edits, and the proofreader proofreads. The file can then be sent to the Project Manager for approval first (or not), and the file is then returned to the client—and all through XTRF!

So, for all these reasons, XTRF seems to be a very sensible tool to avoid a great deal of unnecessary hassle. The learning curve is not extreme, and the benefits certainly appear to outweigh any negatives this program may have. Please let me know what you think in the comments below, and I’ll certainly try to answer any XTRF-dummy questions you may have!