Create Your Own Private NuGet Server in Windows Azure

Create Your Own Private NuGet Server in Windows Azure

, 5 Feb 2015 CPOL

As an introduction to Windows Azure, this article will guide you step by step to create your own private NuGet server in Windows Azure.

Is your email address OK? You are signed up for our newsletters but your email address is either unconfirmed, or has not been reconfirmed in a long time. Please click here to have a confirmation email sent so we can confirm your email address and start sending you newsletters again. Alternatively, you can update your subscriptions.


Whether you are part of a large development team or working alone on your own side project, you’ll probably want to re-use code across multiple projects.

One neat way of doing it, is to create packages, to store them in a repository and to reference them whenever needed. NuGet packages also allow you to have multiple versions of a same package and to specify any eventual dependencies. If you regularly use NuGet Package Manager from Visual Studio, then you are already very familiar with the concept.

This article will show you how you can create your own private NuGet server and how to host it in Windows Azure.


Do I need to mention you need Visual Studio? Maybe not, but I’ve just done it! Any recent edition should do (screenshots for this article are taken from Visual Studio 2013).

And obviously, you’ll also need a valid subscription to Windows Azure. If you don’t have one yet, you can sign up for a free 30-day trial here.

Create a New NuGet Server

Open Visual Studio. Go to File > New > Project… to create a new project. From the templates, select ASP.NET Empty Web Application, as follows:

new empty web application

The Solution Explorer should show an empty solution, as follows:

Empty solution

Now, we’ll use the official NuGet repository to add NuGet.Server to our project. Right-click on References and select Manage NuGet Packages… . Search for NuGet.Server and click Install.

select and install nuget server

Now, the solution should look like this:

solution with nuget server

Press F6 and ensure the solution builds successfully.

We’re almost ready. There’s just one more thing to do before we can run and deploy our code, which is to review our configuration. Open up web.config and review the following settings.

        Determines if an Api Key is required to push\delete packages from the server.
<add key="requireApiKey" value="true"/>
        Set the value here to allow people to push/delete packages from the server.
        NOTE: This is a shared key (password) for all users.
<add key="apiKey" value="Xx5TJbXBe9jEvAfGxV7x"/>
        Change the path to the packages folder. Default is ~/Packages.
        This can be a virtual or physical path.
<add key="packagesPath" value=""/>

To ensure only authorized users will be able to add and delete packages, set requireApiKey to true and setapiKey to the specific key you want to use. (Please make sure to use a different key than the one given in this example). Leave packagesPath to its default value.

Press F5 to run the server. You should see the following home page:

you are running nuget server

Now that we’ve got a NuGet server up and running locally, let’s deploy it to Windows Azure.

Deploy to Windows Azure

The integration with Windows Azure from Visual Studio is excellent and you can create your new website and deploy to it directly from Visual Studio. In the Solution Explorer, right click on NuGetServer project and click onPublish…

right click and publish

From the Profile section, select Microsoft Azure Websites.

select azure and publish

Click sign-in and authenticate with the email address used when you signed up for Windows Azure.

sign in

Now that you are signed in, click New… to create a new website:

signed in

Chose a site name that has not be taken already. I’m going to use code-project-nugetserver for the remainder of this article. The Nuget server will then be available at: (of course, you should use a different name as a reader may have already used it).

Unless you have multiple subscriptions, keep the default one. Chose a region that will be close to your users in order to improve performance. There is no need for a database for this project.

create website in azure

Now, click Create to create the website in Azure. Once it’s created, you’ll be shown the final screen before publication. It contains connection details, such as the address of the site, the username and the password. All fields should be correctly pre-populated and you can click Validate Connection to ensure the details are correct.

When you are ready, click Publish to publish the NuGet server to the website.

validate connection and publish

Now go to (remember it was recommended you chose a different name, so the first part of the URL should be different for you) to ensure the server is up and running. You should see something like:

running live

Congratulations, you’ve got your NuGet server up and running!

Publish your First Package

Download NuGet.exe from (or check for the latest version) and make sure it’s in your path so you can run it from the command line. Indeed, NuGet.exe is a command line tool which allows you to create and to publish packages. For the purpose of this article, I’ve attached a sample package (Sample.Package., and if you want to read more about how to create NuGet packages, there is an excellent documentation on

You are now ready to publish you first package. From the command line, run:

nuget push Sample.Package. -s Xx5TJbXBe9jEvAfGxV7x


You can double check your packages has been successfully published by going to Ensure Sample.Package. is listed in the page:


Download Your Own Packages from Visual Studio

Now that you have your own NuGet Server, you can configure Visual Studio Package Manager to serve your own packages. In Visual Studio, go to Tools > Options > NuGet Package Manager > Packages Sources. Click on the + sign (top right corner) to add a new source. Give it a name in the Name field, for instance My Packagesand set the Source to

add nuget source to visual studio

Now, you can add your own packages to your projects. For a given project, right-click on References and selectManage NuGet Packages… . On the left hand-side, select My Packages, andSample.Package. should be listed:

download package

You now have a mature development environment where you can publish packages for re-use across multiple projects.

Points of Interest

In this article, I’ve covered in detail how to create your own private NuGet server and how to publish it to Windows Azure. This is quite simple to set up and your server should be running from the cloud in less than 20 minutes.

Bundle up your code in packages and publish them to share with your development team or for yourself to re-use in future projects. You can also use NuGet packages for deployment purpose: I will cover how to deploy code with Octopus Deploy in a future article.

One of the great advantages of Windows Azure is scalability and I will cover in detail in a separate article how you can set up your website to automatically scale up or down based on your server workload.

Gotcha: If you don’t want to store the NuGet packages in the default folder, make sure you specify a relative path. Your server is running in IIS alongside a number of other websites. The security model in Azure makes sure that each website runs in isolation and therefore has only got access to the root folder of the website.

Please let me know how you get on with your NuGet server. Do you use it at work? Or do you use it at home for a side project? Do you use it for deployments? Have you encounter any limitations or do you have any feature requests?

Thanks for your feedback and happy coding!



How To Make A Multilingual WordPress Site: Best Translation Plugins

How To Make A Multilingual WordPress Site: Best Translation Plugins

How To Make A Multilingual WordPress Site: Best Translation Plugins
Posted: 03.12.15 | by Irena Domingo

WordPress by default is not multilingual. This means that you need to add multilingual functionality through a translation plugin, creating a WordPress Multisite installation or using a translation proxy. In this post I show the best options to create a WordPress website in two or more languages, using automatic machine translations or human translations. You can use free or premium plugins (which cost about $79).

(Originally written on June 21, 2014. Updated on December 3, 2015)



OPTION 1. Installing a WordPress plugin in a standalone WordPress environment

1.1. AUTOMATIC Machine Translations: Google Language Translator
1.2. SEMI-AUTOMATIC Translations

1.2.1. Transposh
1.2.2. Ajax Translator Revolution (premium)

1.3. HUMAN Translations

1.3.1. qTranslateX
1.3.2. Polylang
1.3.3. WPML (premium)

OPTION 2. Using WordPress Multisite: One website per language

2.1. WordPress Multisite (no need to use network plugins)
2.2. WordPress Multisite + Multilingual Network Plugin

2.2.1. Multisite Language Switcher
2.2.2. Zanto
2.2.3. Multilingual Press

OPTION 3. Using a WordPress theme with integrated multilingual system

OPTION 4. WordPress Localization with translation proxy: Easyling


ANNEX. Translation services for WordPress websites


There may be different reasons why you need to translate your WordPress website into other languages:

You are designing a website in a country that uses multiple languages (in Canada, English and French; in Switzerland, French, German and Italian; etc.)
You want to make a Spanish version to sell your products or services in other parts of the world or a Russian version for russian customers.
Or just want to have your web page in several languages to reach a wider audience.
Choosing the most suitable translation plugin for your needs will take some time. If you have a look at the WordPress Plugin Directory for a list of multilingual Plugins you’ll find many options.

WordPress does not offer a simple solution for building multilingual websites. There are several ways to make a multilingual site. They can be divided into 4 groups:

Option 1: Using a translation plugin in a single WordPress environment (the most common way)
Option 2: Using WordPress Multisite environment and a multilingual network plugin
Option 3: Using a WordPress theme with integrated multilingual system
Option 4: WordPress localization with translation proxy
In this article, I’d like to guide you through the different options available to have a multilanguage WordPress site. Which is the best option? It depends on many factors:

Translation – Do you want to use machine translation or human translation?
Cost – What’s your budget for the multilingual project?
Support – Do you want to have technical support?
Speed – How can you provide a good user experience without decreasing the speed of the application?
Size – How large is your website?
Linking – Does each post or page always have a translation and do they need to be linked to each other?
User profile – Are you a website owner, a freelance translator or a language service provider?

Since WordPress 4.1 you can change your site language (and install new languages) from the WordPress dashboard. You don’t need to modify WPLANG in wp-config.php file (which has disappeared). Go to Settings > General > Site Language, and select a new language (or install a new one). More info: WordPress 100% In My Language
Before starting a multilingual WordPress site is highly recommended choosing a multilingual theme already translated into other languages. More info: A Guide to Choosing a Multilingual WordPress Theme
You can choose different URL formats when building a multilingual website. More info in this article: Domain, Subdomain, Subdirectory, Languages and WordPress
Also you should implement a multilingual SEO strategy for search engines (Google, Bing, Yandex –Russia- or Baidu –China-). More info in this post: Multilingual SEO for WordPress Sites

OPTION 1. Installing a WordPress plugin in a standalone WordPress environment

You can install a WordPress translation plugin for automatic or human translations in a standalone WordPress environment. Let’s review the most popular plugins.

1.1. AUTOMATIC Machine Translations: Google Language Translator

Google Language Translator – WordPress Plugin

Google Language Translator – Ratings and downloads

Google Language Translator is a plugin that can be used only for automatic machine translations. This free plugin allows you to insert the Google Language Translator tool onto your website using shortcode.


It’s the cheapest option. You don’t need to perform the costly task of translating your website or hire a translator.

Translations often don’t make sense. Search engines could consider them as spam. What to do in these cases is prevent these translations from being indexed using the robots.txt file and allowing users to request the translation via a widget.
Conclusion: the best option to use automatic machine translations.

More Details

1.2. SEMI-AUTOMATIC Machine Translations

1.2.1. Transposh

Transposh WordPress Translation Plugin

Transposh WordPress Translation – Ratings and downloadsTransposh is a free plugin that allows automatic translations, but with the advantage that it allows you to combine automatic translation with human translation. 82 languages are automatically translated and can be corrected with ease.


It’s free and allows you to combine machine translation with manual translations.

Automatic machine translations performed are not very accurate so it’s recommended to make manual corrections.
Conclusion: a great option that it allows you to combine machine translation with manual translation.

More Details

1.2.2. Ajax Translator Revolution

Ajax Translator Revolution

Rating Ajax Translator RevolutionIf you are looking for a professional solution for automatic translation Ajax Translator Revolution is probably the best option. It’s a premium plugin that uses Google Translate machine translation service. A total of 63 languages are supported for automatic translation and your site will be translated instantly upon installation.


It’s a plugin highly customizable. You can translate everything or exclude sections from the web pages, pages, posts and categories. Show languages flags and names, or just flags, or just names
If your theme doesn’t have a widget area in the location you want, then you can use the custom positioning settings to place it anywhere
You will be able to edit the translations manually and make your own translations
Compatible with WooCommerce, WooThemes, BuddyPress, bbPress and Gravity Forms

Automatic translations are not very accurate so it’s recommended to make manual corrections
Price. It costs $ 25
Conclusion: the best plugin for automatic translations. Also, allows you to combine machine translation with manual translation

More Details Live Preview

1.3. HUMAN Translations

1.3.1. qTranslateX

qTranslate WordPress Plugin

QtranslateX is based on qTranslate (already disappeared), plugin that became the most popular for multilingual WordPress sites. This plugin store all languages alternatives for each post in the same post.


It’s free. You can switch from one language to another by simple tabs on the edit panel in WordPress.
Does not create additional tables in the database.

Limited support. When a new version of WordPress appears, qTranslateX may take time to get a compatible update. I have to admit that I have not had very good experiences with this plugin.
Some themes and plugins don’t work properly with this plugin.
Conclusion: the most popular free multilingual plugin, but not the best (in my opinion, of course).

More Details

1.3.2. Polylang

Polylang WordPress Translation Plugin

Polylang WordPress Plugin – Ratings and DownloadsPolylang is a free plugin that is easy to use with great support. The users give to this plugin a high score (4,8 out of 5), which gives an idea of the quality of this plugin. I think it’s the best free option.


It’s free, easy to use, and very light-weight.
It offers great support.
You can translate posts, pages, widgets, categories, tags, media, menus, custom post types, custom taxonomies, sticky posts and all default WordPress widgets are supported.

The plugin has been developed by one person. If the developer doesn’t find the time to keep the plugin up-to-date, you could find your multilingual web site incompatible with WordPress.
Documentation can be improved.
Some themes don’t work properly with this plugin.
Conclusion: the best free multilingual plugin in a standalone WordPress environment

More Details

1.3.3. WPML (premium plugin)

WPML WordPress Multilingual Plugin

Sometimes free WordPress plugins just don’t offer what you are looking: frequent updates, technical support, the functionality or the look.

WPML is a premium plugin but not very expensive (between $29 and $79 ). In my opinion it is the best option to translate a web page in WordPress. You won’t have to worry anymore about support and updates.

WPML has the support of a company and a team of professional developers, which overcomes the disadvantages of previous free plugins (qTranslate and Polylang). So far it’s the most serious option to work with multilingual WordPress websites. It’s the plugin I use on my projects.


No need to worry more about technical support or updates. The documentation for the proper use of this plugin is very complete: WPML manual – A guide for site owners and translators (PDF 13 Mb).
It’s very easy to use. With WPML you can translate every element of your website and easily configure domains, subdomains and subdirectories into multiple languages.
You can translate all SEO options. WPML lets you do SEO for each language separately with WordPress SEO by Yoast plugin or other SEO plugins (Article: Using WordPress SEO by Yoast with WPML).
It supports main WordPress themes: StudioPress (Genesis Framework), Elegant Themes (Divi Theme is an excellent choice for a multilingual website), many Themeforest themes, etc. The plugin lets you build and run multilingual e-commerce sites with WooCommerce (LIST of Multilingual Ready Themes).
Includes a translation management plugin that allows XLIFF interface. You can turn ordinary WordPress users into Translators. Also you can hire world-class translators from within the WordPress admin dashboard, get affordable rates (about $0,09 / word) and enjoy a simple translation workflow (ICanLocalize translation services).
The license is offered for unlimited sites.
You can request refunds until 30 days of your purchase date. They will refund 100% of your payment – no questions asked (Refunds Policy). However, you will no longer have access to updates or technical support.

It is a commercial plugin that costs $29 on the Multilingual Blog version (annual renewal costs $15) and $79 on Multilingual CMS version (annual renewal costs $39). If you want to purchase a perpetual license must pay $195, but I can assure you it’s worth
Create additional tables in the database can sometimes slow the admin panel but not your website.
Conclusion: the best plugin to build a multilingual site in a standalone WordPress environment.

Buy WPML Free WPML Manual (PDF 13 Mb)

OPTION 2. WordPress Multisite: One website per language

2.1. WordPress Multisite (no need to use network plugins)

WordPress Multisite Languages

Since WordPress 3.0 it is possible to build a WordPress Multisite installation. It is a collection of sites that share the same WordPress installation. They can share themes and plugins. The individual sites are virtual sites in the sense that they do not have their own directories on your server, although they do have separate directories for media uploads, and they do have separate tables in the database.

This will allow you to create one website per language. The main advantage is that it’s native, using WordPress core functionality, so it’s safe and free to use. This way you can create each website in a different language within your network.

WordPress Multisite Advantages

The main advantage over the WPML plugin is that WordPress will be native in every language. This means you can have a primary address (, a subdomain or subdirectory for the Spanish version ( or, one for the French version ( or, etc.
If you need to set up multiple sites across multiple domains (,,, etc), you can use the WordPress MU Domain Mapping plugin as well – as long as the domains are all hosted on the same server.
It’s an excellent option for large and complex sites, offering minor compatibility issues without additional costs.
WordPress Multisite Disadvantages

It is more difficult to configure and manage:
First, you have to create a network of sites by using the multisite feature.
Once installed, every time you make an adjustment (themes, plugins, menus, widgets, etc) you must port it to all the websites. If there are just two languages that’s not a big deal, but with three or more it can be a big problem.
Also, keep in mind that some plugins an themes do not work properly on Multisite installations.
WordPress Multisite was not originally intended for creating multilingual website.
Managing translation of content is more laborious because it’s easy to lose track of the contents which have been translated or no.
In this option, you only need to insert a language switcher into the header to being redirected to the homepage when switching from one language to another. Many multilingual websites are very different in each language so it’s not always necessary link contents (posts, pages, categories, tags, etc.).

Conclusion: The best option when each post or page don’t need to be linked to each other

WordPress Multisite

Enter Your Email
Join and get the WordPress Multilingual Guide
4 or 5 emails per year

2.2. WordPress Multisite + Multilingual Network Plugin

New plugins have been developed to avoid disadvantages of option 2.1.: Multisite Language Switcher, Zanto and Multilingual Press. These plugins allows you to synchronize posts and pages in each language. For example, you may want to link the translated content in different languages, to avoid being redirected to the homepage when switching from one language to another. Let’s review these plugins.

2.2.1. Multisite Language Switcher

Multisite Language Switcher

Multisite Language SwitcherMultisite Language Switcher – Rating is a free an easy to use plugin ( that will help you to manage multilingual content in a multisite installation. This plugin enables you to manage translations of posts, pages, custom post types, categories, tags and custom taxonomies. You can use a widget to link to all sites.

With 82.000 downloads, the users give to this plugin a high score (4,8 out of 5). It’s an excellent free option for WordPress Multisite.

It’s free and very easy to set up. There are no “pro” features which you have to pay for.
It offers great support: 16 of 17 support threads in the last two months have been resolved (June 2014)
You can translate and link posts, pages, custom post types, categories, tags and custom taxonomies.
If you disable the plugin, all sites will still work as separate sites.
Extensions: Multisite Language Switcher Comments (All comments posted on translation-joined pages are showed on all translation-joined posts)
Conclusion: the best free multilingual plugin for WordPress Multisite

More Details

2.2.2. Zanto

Zanto Plugin WordPress

Zanto ratingsZanto allows you to convert webpages in a multisite into translations of each other. It provides a language switcher to switch between the translations of pages, posts, custom types, categories and taxonomies. Also keeps track of what has been translated and provides an easy interface.

It’s a recent plugin (1.626 downloads). After testing I think it’s another great free option for WordPress Multisite.

It’s free and very easy to set up.
You can translate everything: posts, pages, custom post types, categories, tags, taxonomies, etc.
You have a customizable language switcher.
Different languages for both: front and backend. Over 60 languages and flags.
Integrated support for domain mapping plugin.
Each user will have his admin language preferences stored.
If you disable the plugin, all sites will still work as separate sites.
Plugin documentation and tutorials here:

Conclusion: a great free plugin for WordPress Multisite

More Details

2.2.3. Multilingual Press

Multilingual Press Plugin Review

Multilingual Press – RatingMultilingual Press allows you connect multiple sites as language alternatives in a multisite and use a customizable widget to link to all sites.

You can set a main language for each site, create relationships, and start translating. You get a new field to create a linked post on all the connected sites automatically. They are accessible via the post/page editor – you can switch back and forth to translate them.

With 90.000 downloads (january 2015), the users give to this plugin a high score (4,4 out of 5)

It’s a free version and very easy to use
You can set up unlimited site relationships in the site manager.
Language Manager with 174 editable languages.
It will allow you to view the translations for each post (or page) underneath the post editor.
You can edit all translations for a post from the original post editor without the need to switch sites.
You can duplicate sites. This is a great option because you can use one site as template for new sites. You can copy everything: Posts, pages, settings for plugins, themes, navigation menus, categories, tags, custom taxonomies and attachments.
Change relationships between translations or connect existing posts.
Automatically redirect to the user’s preferred language version of a post.

Conclusion: the best multilingual plugin for WordPress Multisite, but you’ll have to pay if you need support (99 $ – 1 year).

More Details

OPTION 3. Using a WordPress theme with integrated multilingual system

AitThemes Multilingual Themes

AitThemes club HomepageThe most common way to make a multilingual website is installing a translation plugin in your WordPress theme. However, recently have appeared WordPress themes that come with an integrated multilingual system.

The best option I’ve found is AitThemes Club, first multilingual themes on the market (according to them).

All AitThemes are multilingual right out of the box. Themes come with built-in multilingual support, no third party plugin is required. You can simply select your language and start building your WordPress website.


You can translate everything: pages, posts, custom post types, widgets, categories, etc.
You can use the themes in your own native language or create a WordPress website in several languages
No WPML or third party plugin is required. Themes come with AIT Languages plugin to create easily a multilingual website
All parts of the theme, back-end and front-end are already translated to over 18 languages. You will never handle .po files or do the theme translation on your own
Updates, technical support and comprehensive documentation:
How to translate website content
How to work with languages options (videotutorial).

You only have many multilingual themes to choose from (list of themes). However if you use WPML you have hundreds of compatible WordPress themes to choose from (StudioPress, ElegantThemes, many ThemeForest themes, etc)
Price. You can purchase single WordPress theme ($ 45) or access to all WordPress AitThemes ($ 165), but you don’t need to spend money with a thrid party translation plugin.
Conclusion: an excellent option to create a multilanguage WordPress site without using third party plugins.

AitThemes Documentation

OPTION 4. WordPress Localization with translation Proxy: Easyling

Easyling Translation Proxy

A translation proxy works as a layer on top of your site allowing you to manage translated content in the cloud. No additional translated website version is created because the translation proxy works as a layer: it removes the original text from the site and inserts the translated text on the fly.

Easyling is the most popular proxy-based website translation solution. It crawls your web and finds all the pages, posts and texts. Then you can do the translation yourself using live editing or export as an XLIFF file and use your favourite CAT tool.

Once the translation of your WordPress is done, Easyling for WordPress plugin automatically downloads your translations from Easyling, and presents it to your visitors using domains, subdomains or subdirectories.

Easyling for WordPress Plugin


Word count and content extraction to XLIFF
Translation preview. Works as a layer on top of existing site and translators can view their translation on site in real time and adapt text if needed.
Machine translation support
Automatic change detection and collaboration workflow.

Price. You pay for word count ($1,2 per thousand pages) and for the translation tool ($2,4 per thousand unique source words and $12 per thousand translated unique source words).
Users can’t edit pages and posts from the WordPress dashboard.
Although it is an intuitive tool, learning takes time
Conclusion: Translation proxy is a great tool and I think is a good option for language service providers

Easyling Website


As you can see, there is no a better or worse solution to have your blog or WordPress site in two or more languages. It depends on many factors: functionality, price, machine or human translations, ease to manage, technical support, SEO, etc.

If you don’t want to spend your money with plugins, I recommend you to use Polylang or Zanto / Multisite Language Switcher (WordPress Multisite). If you want support and updates and money it’s not a problem, use WPML (single WordPress), Multilingual Press (WordPress Multisite) or a WordPress premium theme with integrated multilingual system such as AitThemes.Club.
If you’re a WordPress beginner user you can use option 1: WPML or Polylang.
If you have a small or medium site, use WPML. If you have a large site, use Multisite (Multilingual Press, Zanto or Multisite Language Switcher).
If you don’t need to link posts and pages, then go Multisite (no need to use plugins). Otherwise you can use WPML or Multisite + Network plugin.
If Search Engine Optimization (SEO) is important for you, don’t use automated translation. However if you want to use automatic translations, Ajax Revolution Translator is the best choice since allows you also make your own translations.
If you’re a language service provider you might want to use Easyling.
In summary, if you want to create a professional, easy to manage, multilingual WordPress website, I recommend you use a professional payment solution with good support such as WPML (single WordPress), Multilingual Press (WordPress Multisite) or AitThemes (multilingual WordPress themes right out of the box). In other cases it may be enough to use a free plugin such as Polylang (single WordPress) or Multisite Language Switcher (WordPress Multisite).

I hope this article will help you to choose the best option for you.

ANNEX. Translations services for WordPress websites

Once you’ve already decided what plugin or solution you will use to translate your WordPress website, you’ll probably need professional translators. You have different options according to your budget and the quiality level:

1. Fiverr. If I do not have much budget you can find a translator on Fiverr, a global online marketplace offering services (including translation services), beginning at a cost of $5 per job performed (from which it gets its name). The cost per word is approximately 1 cent. Cheap but quality may be low. You can find very good translators but also very bad.

Fiverr Translation Services, Translation Professionals

2. TextMaster. A crowdsourced translation marketplace ideal for web content. According to the quality level prices start from 3 cents per word (More info in this article)

TextMaster | Translation Service | Web Content Writing

3. ICanlocalize. A professional translation service fully integrated into WPML. Translation rates are between 9 to 14 cents / word, depending on the language pairs and required fields of expertise.

ICanLocalize WordPress Translation Services

This is the third article in the series on WordPress 100% Localized and Translated

How to Easily Create a Multilingual WordPress Site

How to Easily Create a Multilingual WordPress Site

Do you want to translate your WordPress site in multiple languages? Wondering where to start? In this article, we will show you how to easily create a multilingual WordPress site.
No you do not need to setup a multi-site or have separate WordPress installs for each language. You will be able to easily translate your WordPress posts, pages, tags, categories, and themes into as many languages as you like.
Creating multilingual websites
We will look at both common approaches adopted by WordPress multilingual site owners.
The first approach allows you to manually translate all the content into languages of your choice.
The second method does not actually create a multilingual site, but instead it adds machine translations of your existing content by using the Google Translate service.
It goes without saying that manually translating your content is a much better approach. This allows you to maintain quality throughout your website. You can translate the content yourself or hire professionals to do that.
If you do not have the resources, and you still want users to be able to see content in other languages, then you can go for Google Translate. This will add a multi-language switcher for users to select a language, and the content will be translated using Google Translate. The downside of this approach is that the quality of translations will not be as good.
Let’s start by looking into building a multilingual WordPress site with manual translations.
Video Tutorial

If you don’t like the video or need more instructions, then continue reading.
Creating a Multilingual WordPress Site (Human Translation)

First thing you need to do is install and activate the Polylang plugin. Upon activation, you need to visit Settings » Languages to configure the plugin.
Polylang settings page
The language settings page is divided into three tabs. The first tab is labeled ‘Languages’. This is where you add the languages you want to use on your site.
You will need to add the default language, as well as select all other languages that users can choose on your site.
After adding the languages, switch to the ‘Strings Translations’ tab. Here you need to translate site title, description, and then choose the date and time format.
Translating strings
Last step in the configuration is the Settings tab. This is where you can choose a default language for your site and other technical settings.
Setting up a URL structure
For most beginners, we recommend not changing the URL, so select the first option. Why? Because if you ever turn off this plugin, then all those links will be broken.
For those who are looking to take full advantage of multi language SEO, then we recommend that you choose the second option for pretty permalinks as shown in the screenshot above.
You should select the option for detecting browser’s preferred language, and automatically show them the content in their preferred language. By doing this, the user will see the content in their preferred language and can switch the language if needed.
Once you are done, click on the save changes button to store your settings.
Adding Multilingual Content in WordPress

Polylang makes it super easy to add content in different languages. Simply create a new post/page or edit an existing one. On the post edit screen, you will notice the languages meta box.
Adding Multi-Lingual Content in WordPress using Polylang plugin
Your default language will automatically be selected, so you can first add content in your default language, and then translate it into others.
To translate, you need to click on the + button next to a language and then add content for that language.
A multi-lingual blog post in WordPress created with Polylang
Repeat the process for all languages. Once you are done, you can publish your posts and pages.
It’s important to note that Polylang works with custom post types, so it can definitely help you make your woocommerce store multilingual.
Translating Categories, Tags, and Custom Taxonomies

You can also translate categories and tags, or any custom taxonomies you may be using.
If you want to translate categories, then go to Posts » Categories.
Translating categories
Add a category in your default language and then click on the plus icon for each language to start adding translations.
Displaying Multi Language Switcher on Your WordPress Site

Adding a language switcher allows users to select a language when viewing your site. Polylang makes it super simple. Just go to Appearance » Widgets and add the language switcher widget to your sidebar or another widget-ready area.
Language switcher
You can choose a drop down, or use language names with flags. Once you are done, click the save button to store your widget settings.
You can now preview your site to see the language switcher in action.
Language switcher on a live WordPress site
Using Google Translate to Create a Multilingual Site in WordPress

While adding human translations definitely creates a better user experience, you may not have the resources or time to do that. In that case, you can try using Google Translate to automatically translate content on your site.
First thing you need to do is install and activate the Google Language Translator plugin. Upon activation, visit Settings » Google Language Translator to configure the plugin.
Google Language Translator plugin
The plugin allows you to select the languages available with Google Translate. You can even remove Google’s branding from translation. This is a highly customizable plugin, so you need to go through the settings and configure it to your liking.
For more details check out our tutorial on how to add Google Translate in WordPress with video and text instructions on how to set up the plugin.
That’s all, we hope this article helped you learn how to create a multilingual site in WordPress. You should also look at our article on how to install WordPress in your language.
If you are looking for a multilingual WordPress theme also referred to translation-ready themes, check out our guide on how to find translation ready WordPress themes that also has an easy way to translate existing WordPress themes.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Google+.

Bootstrap: You’re Doing It Wrong

Bootstrap: You’re Doing It Wrong

JANUARY 27, 2014
Bootstrap is a powerful web presentation framework formerly known as Twitter Bootstrap. I want to address some misconceptions about the framework and describe ways people use Bootstrap incorrectly. I will reveal the causes and offer corrections. I do not claim that everyone should use Bootstrap but I believe the majority of sites would benefit from Bootstrap or a similar framework.

Bootstrap came to be in the best way for a framework. It was extracted from a working application and organized for reuse. Bootstrap was extracted from Twitter’s web site for use across all of Twitter’s web UIs. In a similar manner, Ruby on Rails was extracted from Basecamp. Frameworks created in this way are more likely to be useful than those based on theories of best practice.

Bootstrap is not the only option for a front-end web framework, but it is the most popular. I believe that everyone should base their CSS on a framework as their is no point recreating common elements and correcting the common shortcomings in CSS browser support. There are lightweight libraries available which only normalize layout across browsers while others also provide responsive layout across multiple form factors.

It is common to hear that Bootstrap is bloated and limits your options if you adopt it. Another complaint is that Bootstrap tries to be a theme and not just a presentation framework. These attitudes are articulately expressed by my friend Tim G. Thomas in a recent presentation. Please take a moment to watch his talk from 17:23 to 20:05. You should watch the entire talk if you have the time.

Tim G. Thomas: A Developer’s Guide to Design Frameworks (and More!)

My criticisms of Tim’s opinions are not criticisms of Tim. His opinions about Bootstrap are common misconceptions. Here are Tim’s comments along with my evaluation of their accuracy:

Comprehensive – True
Huge, Gargantuan – False
Does absolutely everything for you – False
The goal is to do everything for you – False
You don’t need a designer – False
Everything will be fine and happy; rainbows and Unicorns – False
Good for rapid prototyping only if you never plan to release your code into production – False
Paints you into a corner – False
Difficult to extend on top of it – False
Good for Personal Tools – True
Be aware of its strengths and limitations – True
It does have quite a few limitations – False
There are themes you can download – True
There are people specializing in creating Bootstrap themes – True
This is a “red flag” – False
You can get started with it quickly – True
You have to read through a lot of documentation. – True
Low in efficiency – False
You learn a lot with it but you don’t learn CSS – True
It’s impossible to know exactly what is going on where – False
Not extensible unless you are a professional Bootstrap theme designer – False
I believe Tim’s misunderstanding and that of others like him comes from experience using Bootstrap incorrectly. Here are my recommendations for using Bootstrap correctly:

Learn CSS.
Anyone considering using Bootstrap, or any other web presentation framework, must first learn CSS. This is not optional. If you are building web UIs, you must understand the universally used layout technology. Bootstrap is not meant to teach you CSS. If you paint yourself into a corner using Bootstrap because you do not understand CSS, you are responsible for your situation. Be a professional. Learn your medium. If you use Bootstrap assuming you don’t need to know CSS, it’s not the framework’s fault when things go awry.
Use a CSS meta syntax.
Anyone building web UIs these days, should use a CSS meta syntax. There are two options, LESS and SASS. SASS has two syntaxes, the more modern and recommended syntax is SCSS but I only hear people refer to it as SASS. Pick one, LESS or SASS I do not care which, and use it to generate your static CSS for display. Just do it. You will not regret it. To do otherwise is to waste time, limit productivity and be prone to error.
Use the Bootstrap LESS source code.
Using static CSS is the number one mistake people make when using Bootstrap. Tim says he had the unfortunate job of trying to extend on top of Bootstrap and finally recommended that his client “get rid of the whole thing”. I understand this sentiment. If I did not understand Bootstrap and was told to extend on top of static CSS generated from the framework, I would probably do the same. It is easy to understand what is going on where if you use the LESS source and not static CSS.The Bootstrap team encourages this mistake. They actively encourage users to download the entire framework as static CSS on their home page. To be fair, they also have a link to download the LESS source but I recommend cloning the source from the GitHub repository instead. This way you can easily retrieve and experiment with updates in your own projects.
The Bootstrap development team further exacerbates the issue by providing a “customize and download” form. This form encourages you to generate custom, static CSS. It presents you with options to customize the compiled CSS. On this page, you will see all of the modules available within Bootstrap and you can select any that you want in your project. You will also see the variables available for customization within Bootstrap. There are fields to customize each value. Although the result is still static CSS, these options provide you with the opportunity to counter the assertion that all Bootstrap sites look alike. If you study this page, you can learn a great deal about how to use Bootstrap effectively.

Tim recommends using the full framework with default styling for personal or internal projects. I agree but with the caveat that you use the LESS source to generate your CSS. While a site may begin life as a personal or internal project, these things can grow beyond their initial intentions. Starting with the LESS source keeps your options open with little overhead in taking the site live.

Using the Bootstrap LESS source forces your hand in the choice between LESS and SASS, but if you choose to use Bootstrap, you ipso facto choose LESS as well. I’ve heard that if you have a Rails application, you should use Bootstrap-SASS. This annoys me because there is nothing inherently better about SASS just because the Rails team chose it as the default. The Rails team made Prototype the default JavaScript framework for years after most developers replaced it with jQuery immediately upon creating a new Rails project.

Bootstrap is a LESS project. Use LESS with Bootstrap. There is no advantage to using SASS. The SASS port exists to appease Rails snobs that think the team has some special insight into your application’s requirements when choosing their defaults. The Rails team chooses reasonable defaults, but there is no reason you should stick with them all and I don’t know anyone who does. The use of SASS is no different than any other default that you may replace if your needs benefit from that choice.

Be selective.
You don’t have to use every feature of Bootstrap in your production app. Bootstrap is a buffet. You can certainly use the entire framework with it’s default configuration to quickly generate a UI that handles multiple browsers and formats gracefully. Bootstrap does not do everything for you, but it provides a set of reasonable defaults for you to choose from. Although the framework is comprehensive, you don’t have to use it all or any specific part of it.In addition to the LESS code, bootstrap includes JavaScript components. The JavaScript libraries are a convenience and can be included or excluded as you see fit. The JavaScript libraries are jQuery plugins for common use cases. These plugins work well with Bootstrap styles and elements by default.
Read all of the documentation.
Become familiar with the elements of Bootstrap you choose to use in your site. This is not only true for Bootstrap. You should do this for any framework or library you select for your project.Tim identified the need to read a lot of documentation as a shortcoming of Bootstrap. Why is documentation a shortcoming? Thorough documentation is an asset. The Bootstrap documentation is well organized. It is easy to find the section relevant to your questions.
Study the Bootstrap source.
The bootstrap LESS source is very well organized and easy to read. It is organized into modules of increasing granularity. This is one reason it’s written in LESS. Notice how bootstrap.less simply includes each of the component files. You can follow the includes to see what modules make up each Bootstrap feature. There is no requirement that you include bootstrap.less in your project. You can include only the modules that are suitable for your needs in an a la carte manner. Bootstrap is imminently extensible and customizable.
Avoid looking like a “Bootstrap site”.
A common complaint against Bootstrap is that all Bootstrap sites look alike. It isn’t difficult to make bootstrap distinctive and follow a custom design. On client applications, I include the bootstrap LESS libraries, then my own overrides. I usually grab the LESS from a Bootswatch that approximates the site design, then I begin tweaking from there to meet the designer’s specifications. This allows me to start with overrides from a consistent layout and tweak it to my needs. This pattern has served me and my clients well.
Use a Bootstrap template, if you do not have access to a designer.
Yes, there are people making a living creating custom styles and themes based on Bootstrap. I do not see this as a shortcoming of the framework in any way.I am not a designer. My personal site is built on WordPress with Bootstrap. Because I don’t do web design, I bought a simple design template. After looking at many templates, WordPress themes etc., I chose a template based on bootstrap. I liked it best of all the templates I reviewed and it had the added benefit that I wouldn’t have to convert the styles to use bootstrap. Even so, I’ve made such a conversion before and it wasn’t difficult. I don’t think it looks like a Bootstrap site. It looks sufficiently distinctive for my needs.
The template I purchased was not a WordPress theme so I chose a base WordPress theme that depends on the bootstrap LESS source and allows extensibility through custom LESS. I created a child theme using my custom template. I ripped out all the default Bootstrap styles in the template in order to depend on the bootstrap LESS in the base theme. I ended up with few unique styles and overrides from the template that I purchased and let Bootstrap defaults from the base theme handle the rest.

I made a few overrides of Bootstrap defaults in custom LESS. I had some issues overriding a few defaults. I won’t deny that I made some ugly hacks. It wasn’t worth going any further for my simple blog. If this were a client site, I would have done things cleaner, but I wouldn’t have had to deal with the overhead of WordPress either.

If possible, use a designer.
The Bootstrap website never suggests that you do not need a designer. Bootstrap is not necessarily a “theme” but it can mistakenly be used in that manner. By default, Bootstrap styles default HTML elements in a more pleasing manner than the browser defaults. You should use these default styles only as a starting point and customize them to suit your designer’s specifications.Bootstrap does not limit extensibility. In the past, it was difficult to customize certain elements provided by bootstrap, especially the top bar. The framework has matured and become more configurable with subsequent releases. Although still not flawless in this regard, it is much improved.
Beware that backwards compatibility is not guaranteed.
The team makes this clear. Mistakes are made in any initial design. For example, one criticism of Bootstrap is that the classes aren’t named semantically. By forgoing backwards compatibility, the team is able to correct past design mistakes and keep up as web standards and practices evolve and grow.To protect yourself, clone the LESS source from your version’s release branch into your project. Then you can pull any fixes or updates to that version into your project without suffering from breaking changes such as renaming default styles. When a new version is released, you can try that branch and determine if it is worth the trouble to update your UI to accommodate changes in the new version.
Bootstrap isn’t for everyone or every project. A good library or framework follows the Pareto Principle of meeting 80% of use cases. This is where Bootstrap is most useful. You need to make informed choices when choosing or rejecting a framework. I encourage you to explore Bootstrap following my recommendations. I think you will be pleasantly surprised by the utility and ease of use this rapidly evolving framework provides.

A successful Git branching model


By Vincent Driessen
on Tuesday, January 05, 2010

In this post I present the development model that I’ve introduced for some of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.

It focuses around Git as the tool for the versioning of all of our source code. (By the way, if you’re interested in Git, our company GitPrime provides some awesome realtime data analytics on software engineering performance.)

Why git?

For a thorough discussion on the pros and cons of Git compared to centralized source code control systems, see the web. There are plenty of flame wars going on there. As a developer, I prefer Git above all other tools around today. Git really changed the way developers think of merging and branching. From the classic CVS/Subversion world I came from, merging/branching has always been considered a bit scary (“beware of merge conflicts, they bite you!”) and something you only do every once in a while.

But with Git, these actions are extremely cheap and simple, and they are considered one of the core parts of your daily workflow, really. For example, in CVS/Subversion books, branching and merging is first discussed in the later chapters (for advanced users), while in every Git book, it’s already covered in chapter 3 (basics).

As a consequence of its simplicity and repetitive nature, branching and merging are no longer something to be afraid of. Version control tools are supposed to assist in branching/merging more than anything else.

Enough about the tools, let’s head onto the development model. The model that I’m going to present here is essentially no more than a set of procedures that every team member has to follow in order to come to a managed software development process.

Decentralized but centralized

The repository setup that we use and that works well with this branching model, is that with a central “truth” repo. Note that this repo is only considered to be the central one (since Git is a DVCS, there is no such thing as a central repo at a technical level). We will refer to this repo as origin, since this name is familiar to all Git users.

Each developer pulls and pushes to origin. But besides the centralized push-pull relationships, each developer may also pull changes from other peers to form sub teams. For example, this might be useful to work together with two or more developers on a big new feature, before pushing the work in progress to origin prematurely. In the figure above, there are subteams of Alice and Bob, Alice and David, and Clair and David.

Technically, this means nothing more than that Alice has defined a Git remote, named bob, pointing to Bob’s repository, and vice versa.

The main branches

At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime:

  • master
  • develop

The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists calleddevelop.

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.

When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. How this is done in detail will be discussed further on.

Therefore, each time when changes are merged back into master, this is a new production releaseby definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.

Supporting branches

Next to the main branches master and develop, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

The different types of branches we may use are:

  • Feature branches
  • Release branches
  • Hotfix branches

Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. We will walk through them in a minute.

By no means are these branches “special” from a technical perspective. The branch types are categorized by how we use them. They are of course plain old Git branches.

Feature branches

May branch off from:
Must merge back into:
Branch naming convention:
anything except master, develop, release-*, or hotfix-*

Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).

Feature branches typically exist in developer repos only, not in origin.

Creating a feature branch

When starting work on a new feature, branch off from the develop branch.

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

Incorporating a finished feature on develop

Finished features may be merged into the develop branch to definitely add them to the upcoming release:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. Compare:

In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used.

Yes, it will create a few more (empty) commit objects, but the gain is much bigger than the cost.

Release branches

May branch off from:
Must merge back into:
develop and master
Branch naming convention:

Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, thedevelop branch is cleared to receive features for the next big release.

The key moment to branch off a new release branch from develop is when develop (almost) reflects the desired state of the new release. At least all features that are targeted for the release-to-be-built must be merged in to develop at this point in time. All features targeted at future releases may not—they must wait until after the release branch is branched off.

It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.

Creating a release branch

Release branches are created from the develop branch. For example, say version 1.1.5 is the current production release and we have a big release coming up. The state of develop is ready for the “next release” and we have decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we branch off and give the release branch a name reflecting the new version number:

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./ 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

After creating a new branch and switching to it, we bump the version number. Here, is a fictional shell script that changes some files in the working copy to reflect the new version. (This can of course be a manual change—the point being that some files change.) Then, the bumped version number is committed.

This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.

Finishing a release branch

When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.

The first two steps in Git:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

The release is now done, and tagged for future reference.

Edit: You might as well want to use the -s or -u <key> flags to sign your tag cryptographically.

To keep the changes made in the release branch, we need to merge those back into develop, though. In Git:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

This step may well lead to a merge conflict (probably even, since we have changed the version number). If so, fix it and commit.

Now we are really done and the release branch may be removed, since we don’t need it anymore:

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

Hotfix branches

May branch off from:
Must merge back into:
develop and master
Branch naming convention:

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.

The essence is that work of team members (on thedevelop branch) can continue, while another person is preparing a quick production fix.

Creating the hotfix branch

Hotfix branches are created from the master branch. For example, say version 1.2 is the current production release running live and causing troubles due to a severe bug. But changes on developare yet unstable. We may then branch off a hotfix branch and start fixing the problem:

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./ 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

Don’t forget to bump the version number after branching off!

Then, fix the bug and commit the fix in one or more separate commits.

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

Finishing a hotfix branch

When finished, the bugfix needs to be merged back into master, but also needs to be merged back into develop, in order to safeguard that the bugfix is included in the next release as well. This is completely similar to how release branches are finished.

First, update master and tag the release.

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

Edit: You might as well want to use the -s or -u <key> flags to sign your tag cryptographically.

Next, include the bugfix in develop, too:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)

Finally, remove the temporary branch:

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).


While there is nothing really shocking new to this branching model, the “big picture” figure that this post began with has turned out to be tremendously useful in our projects. It forms an elegant mental model that is easy to comprehend and allows team members to develop a shared understanding of the branching and releasing processes.

A high-quality PDF version of the figure is provided here. Go ahead and hang it on the wall for quick reference at any time.

Update: And for anyone who requested it: here’s the gitflow-model.src.key of the main diagram image (Apple Keynote).


If you want to get in touch, I’m @nvie on Twitter.

Migrate to Git from SVN

Migrate to Git from SVN
We’ve broken down the SVN-to-Git migration process into 5 simple steps:

Prepare your environment for the migration.
Convert the SVN repository to a local Git repository.
Synchronize the local Git repository when the SVN repository changes.
Share the Git repository with your developers via Bitbucket.
Migrate your development efforts from SVN to Git.
The prepare, convert, and synchronize steps take a SVN commit history and turn it into a Git repository. The best way to manage these first 3 steps is to designate one of your team members as the migration lead (if you’re reading this guide, that person is probably you). All 3 of these steps should be performed on the migration lead’s local computer.

Git Migration: Prepare, clone, sync
After the synchronize phase, the migration lead should have no trouble keeping a local Git repository up-to-date with an SVN counterpart. To share the Git repository, the migration lead can share his local Git repository with other developers by pushing it to Bitbucket, a Git hosting service.

Git Migration: Share the git repo via bitbucket
Once it’s on Bitbucket, other developers can clone the converted Git repository to their local machines, explore its history with Git commands, and begin integrating it into their build processes. However, we advocate a one-way synchronization from SVN to Git until your team is ready to switch to a pure Git workflow. This means that everybody should treat their Git repository as read-only and continue committing to the original SVN repository. The only changes to the Git repository should happen when the migration lead synchronizes it and pushes the updates to Bitbucket.

This provides a clear-cut transition period where your team can get comfortable with Git without interrupting your existing SVN-based workflow. Once you’re confident that your developers are ready to make the switch, the final step in the migration process is to freeze your SVN repository and begin committing with Git instead.

Git migration: Migrate Active Development to Git
This switch should be a very natural process, as the entire Git workflow is already in place and your developers have had all the time they need to get comfortable with it. By this point, you have successfully migrated your project from SVN to Git.

Next up:


Configure the Visual Studio Tools for Apache Cordova

Updated: 9/10/2015

You can download Visual Studio from the Microsoft Download Center. Once you have installed the tools, refer to this topic for additional ways to quickly configure, update, or customize the tools for your environment.

Install dependencies manually

If you choose not to install one or more dependencies with the extension, you can install them later manually.

You can install the dependencies in any order, except for Java. You must install and configure Java before you install the Android SDK. Read the following information and use these links to install dependencies manually.

  • Joyent Node.js

    We recommend installing the x86 version of Node.js.

  • Google Chrome
  • Git Command Line Tools

    When you install Git command line tools, select the option that adds Git to your command prompt path.

    Caution: Git command line tools 1.9.5 are installed by default. Unexpected failures may occur if you install a version prior to 1.9.0.

  • Apache Ant
    • Download and extract Ant to a location like C:/ant-1.x.x
    • Set the ANT_HOME environment variable to point to the preceding location.
    • Add %ANT_HOME%\bin to the system path.

    Note: If you need to set this environment variable manually, see Override system environment variables.

  • 32-bit Oracle Java 7
    • Set the JAVA_HOME environment variable to C:/Program Files/Java/jdk1.7.0_55
    • Add this to the system path: %JAVA_HOME%\bin
    • To avoid out of memory issues, set a *JAVA_OPTIONS environment variable with at least -Xmx512M in it.

    Note: If you need to set this environment variable manually, see Override system environment variables.

  • Android SDK with the following SDK packages:
    • Android SDK Tools (latest version) * Android SDK Platform-tools (latest version)
    • Android SDK Build-tools (19.1, 19.0.3, and 21)
    • Android 5.0 (API level 21) with the following packages:
      • SDK Platform
      • If you want to use the Google Android Emulator to emulate a 5.0.x device:
        • ARM EABI v7a System Image
        • Intel x86 Atom System Image
        • Google APIs (x86 System Image)
        • Google APIs (ARM System Image)
        • If you want to use Cordova 5.0.0 or later:
        • Android 5.1.x (API level 22) with the following packages: SDK platform

      The following illustration shows the minimum required packages in the Android SDK Manager.


      Set the ADT_HOME environment variable to the SDK installation location.

      Add this to the system path: %ADT_HOME%\tools;%ADT_HOME%\platform-tools

      If you need to set this environment variable manually, see Override system environment variables.

      Tip: If you install the Android SDK to its default location on Windows, it gets installed to C:\Program Files (x86)\Android\android-sdk.

  • If you want to use the Google Android Emulator to emulate a 5.1.x device:
    • ARM EABI v7a System Image
    • Intel x86 Atom System Image
    • Google APIs (x86 System Image)
    • Google APIs (ARM System Image)
    • Apple iTunes (x86, x64)
    • WebSocket4Net (required if you’re developing your app on Windows 7)
    • Download WebSocket4Net(0.9) from CodePlex.
    • Unzip the binaries and then unblock net45\Release\WebSocket4Net.dll. To unblock the DLL, open the file Properties for the DLL and choose Unblock in the General tab (at the bottom of the dialog box).
    • After you unblock the DLL, copy net45\Release\WebSocket4Net.dll into the %ProgramFiles(x86)%\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\WebClient\Diagnostics\ToolWindows folder on your computer.

Override system environment variables

Visual Studio detects the configurations for the third-party software you’ve installed, and maintains the installation paths in the following environment variables:

  • ADT_HOME points to the Android installation path.
  • ANT_HOME points to the Ant folder on your computer.
  • GIT_HOME points to the Git installation path.
  • JAVA_HOME points to the Java installation path.

Visual Studio uses these environment variables when building and running your app. You can view the environment variables and revise their values through the Visual Studio Options dialog box. You might want to override the default settings for one of the following reasons:

  • Visual Studio was unable to verify the path. In this case, a warning is displayed next to the environment variable.
  • You have multiple versions of the software installed, and you’d like to use a specific version.
  • You want your global environment path to be different from the local Visual Studio environment.

To override the variables

  1. On the Visual Studio menu bar, choose Tools, Options. 4. In the Options dialog box, chooseTools* for Apache Cordova, and then choose Environment Variable Overrides.
  2. Make your changes:
    • To override a value, select its check box, and then revise the value.
      If the path information is invalid or missing, Visual Studio displays a warning next to that variable.
    • To reset an environment variable to its default value, clear its check box or choose Reset to Default.
  3. Choose the OK button to save your changes and close the dialog box.Environment variables, warning message

Generate a new security PIN

When you start the agent the first time, the generated PIN is valid for a limited amount of time (10 minutes by default). If you don’t connect to the agent before the time expires, or if you want to connect a second client to the agent, you will need to generate a new PIN.

To generate a new security PIN

  1. Stop the agent (or open a second Terminal app window on your Mac and use that to enter the command).
  2. From the Terminal app on your Mac, type:
    remotebuild certificates generate

    Note If you are running an older version of the agent, the preceding command is not supported. Make sure that you update the remotebuild agent by re-installing.

  3. Follow instructions to start the agent on your Mac and configure the agent in Visual Studio.

Generate a new server certificate

For security purposes, the server certificates that pair Visual Studio with the remote agent are tied to your Mac’s IP or host name. If these values have changed, you will need to generate a new server certificate, and then reconfigure Visual Studio with the new values.

To generate a new server certificate

  1. Stop the agent.
  2. From the Terminal app on your Mac, type:
    remotebuild certificates reset

    Note If you are running an older version of the agent, the preceding command is not supported. Make sure that you update the remotebuild agent by re-installing.

  3. When prompted, type “Y” and then type Enter.
  4. From the Terminal app on your Mac, type:
    remotebuild certificates generate  

    –hostname is optional. If omitted, the agent will attempt to determine the hostname automatically.

  5. Follow instructions to start the agent on your Mac and configure the agent in Visual Studio.

Configure the iOS remote agent

You can configure the remote agent using various command line options. For example, you can specify the port to listen for build requests and specify the maximum number of builds to maintain on the file system. (By default, the limit is 10. The agent will remove builds that exceed the maximum on shutdown.)

Caution: Many options have changed between vs-mda-remote and remotebuild.

To configure the remote agent

  • To see a complete list of agent commands, type:
    remotebuild --help

    To see the full list of supported options, type remotebuild --help <*command*>. For example, to see options for the certificates parameter, type:

    remotebuild --help certificates
  • To disable secure mode and enable simple HTTP based connections, type:
    remotebuild –-secure=false

    When you use this option, leave the PIN field blank and make sure to set Secure Mode to False when configuring the agent in Visual Studio.

  • To specify a location for remote agent files, type:
    remotebuild --serverDir <directory>

    where <directory\>is a location on your Mac where log files, builds, and server certificates will be placed. For example, the location could be /Users/username/builds. (Builds will be organized by build number in this location.)

  • To use a background process to capture stdout and stderr to a file (server.log), type:
    remotebuild > server.log 2>&1 &

The server.log file might assist in troubleshooting build issues.

  • To run the agent by using a configuration file instead of command-line parameters, type:
    remotebuild --config <path-to-config-file>

The configuration file must be in JSON format. The startup options and their values must not include dashes. To see a documented configuration file, look at the remotebuild/examples/exampleConfig.json folder in the remote agent installation directory, although you must remove the comments in the file that you use for your configuration. An example of a path you might use when running this command is /Users/<username\>/myConfig.json. The default path where the agent looks for a configuration file is ~/.taco_home/RemoteBuild.config.

Verify the iOS remote agent configuration

Once you have installed the agent, you can verify the remote agent configuration.

To verify the remote agent configuration

  • With the remote agent running, open a second Terminal app window (choose Shell, New Window).
  • From the second Terminal app window on your Mac, type:

    remotebuild test

    Important: This command will fail if the agent is not running in a second window, or if the two instances are not using the same configuration options.

    This command initiates a test build. The output from the command should show the build number and other information about the build, such as its progress.

  • If you started the server on a port other than 3000, use the following command instead to initiate a test build:
    remotebuild test –-server http://localhost:<portNumber>
  • To verify that your developer signing identity is set up correctly for device builds (using the Debug and Release configurations in Visual Studio), type:
    remotebuild test --device
  • To verify that your distribution signing identity is set up correctly for device builds (using the Debug configuration in Visual Studio), type:
    remotebuild test --device

For more information about app provisioning and certificate signing identities, see Package Your App Built with Visual Studio Tools for Apache Cordova.

Reinstall vs-tac

If you see unexpected errors when trying to build the Blank App template after installing Visual Studio Tools for Apache Cordova, you can try clearing your cache and reinstalling the Cordova CLI pre-processor, vs-tac, on your PC. Typically, this is only necessary if you try to build a Cordova app and see the error Cannot find module [modulename].

To clear the cache

  1. Choose Tools, Options, Tools for Apache Cordova, and then choose Cordova Tools.
  2. Choose Clear Cordova Cache.
  3. Close and re-open your project.
  4. Choose Build, Clean Solution, and then rebuild your project.

    Tip: If you have no errors, you do not need to re-install vs-tac. If you still have the same error, then re-install vs-tac.

To re-install vs-tac

  1. Close Visual Studio.
  2. Open a command line and type the following command:
    npm install -g <path-to-vs-tac>

    The default path to vs-tac is C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\ApacheCordovaTools\packages\vs-tac

  3. Re-open Visual Studio. 5. Open your project, choose Build, Clean Solution, and then rebuild your project. If this does not resolve the issue, see the Known Issues.

Configure tools to work with a proxy

If you are using Visual Studio behind a proxy, such as a corporate firewall, you may need to configure proxy settings for the npm package manager and for git before you can use Visual Studio Tools for Apache Cordova.

Important: Using npm proxy settings with recent versions of Node.js can cause Cordova to fail to acquire plugins at the command line or in the configuration designer or when adding platforms required for build. If you encounter unexpected issues (particularly a “TypeError: Request path contains unescaped characters” error), try downgrading Node.js to 0.10.29.

To configure proxy settings for npm package manager

  1. Close Visual Studio.
  2. Open a Visual Studio developer command window (Ctrl + Alt + A) and type the following command.
    npm -g uninstall vs-tac
  3. Open %AppData%\npm\node_modules and verify that the vs-tac folder has been removed.
  4. In the Visual Studio developer command window, type the following command.
    npm config set proxy <proxy-port>

    where proxy-port is the proxy address and port number, such as

  5. Then type this command:
    npm config set https-proxy <proxy-port>

    where proxy-port might be a value such as

  6. Open Visual Studio.
  7. Open your Apache Cordova solution and rebuild your project.

To configure proxy settings for git

  1. Close Visual Studio.
  2. Open a Visual Studio developer command window (Ctrl + Alt + A) and type the following command.
    git config --global http.proxy http://<username>:<password>@<proxy-port>

    where username and password are your proxy username and password; proxy-port might be a value such as

  3. Type this command:
    git config --global https.proxy http://<username>:<password>@<proxy-port>

    where username and password are your proxy username and password; proxy-port might be a value such as

  4. Open Visual Studio.
  5. Open your Apache Cordova solution and rebuild your project.

Did you find this article helpful?

HelpfulNot Helpful