new file mode 100644
--- /dev/null
+++ b/intl/docs/localization.rst
@@ -0,0 +1,170 @@
+============
+Localization
+============
+
+Localization is an aspect of internationalization focused on adapting software to
+the cultural and regional needs.
+
+The boundry between internationalization and localization is fuzzy. At Mozilla
+we refer to localization when we talk about adapting the user interface
+and messages, while interantionalization handled operations on data.
+
+Localization is a broader term than translation because it involves extensive research
+into the target culture, and in result touches not only text and UI translation but also
+cultural adaptation of icons, communication styles, colors, and UX.
+
+Localization at Mozilla
+=======================
+
+At Mozilla localizations are managed by locale communities around the World, who
+are responsible for maintaining the high quality linguistic and cultural adaptation
+of Mozilla software into over 100 locales.
+
+The exact process of localization management differs from project to project, but
+in case of Gecko apps the localization is primarely done via a web localization
+system called Mozilla Pontoon and stored in HG repositories under
+`hg.mozilla.org/l10n-central`.
+
+Developers are expected to maintain their code localizable using localization
+and internationalization systems, and also serve as localizers into the `en-US` locale
+which is used as the `source` locale.
+
+In between those two, there's a sophisticated ecosystem of tools, tests, automation,
+validators and other checks on one hand, and management, release, community
+and quality processes facilitated by the L10n Drivers Team.
+
+Content vs. UI
+==============
+
+The two main categories in localization are content localization vs UI localization.
+
+The former is usually involved when dealing with large blocks of texts such as
+documentation, help articles, marketing materials and legal documents.
+
+The latter is the primary type when handling user interfaces for applications such
+as Firefox or other Gecko applications.
+
+This article will focus on UI localization.
+
+Lifecycle & Workflow
+====================
+
+1) New feature
+--------------
+
+The typical life cycle of a localizable UI starts with a UX/UI or new feature need which
+should be accompanied by the UX mockups involving so called `copy` - the original
+content to be used in the new piece of UI.
+
+2) UX mockup + copy review
+--------------------------
+
+This copy is the first step that gets reviewed by the L10n Drivers Team which tries
+to identify potential cultural and localization challenges that may arise later and
+ensure that the UI is ready for the localization both on the linguistic and cultural,
+and technical level.
+
+3) Patch l10n review
+--------------------
+
+Once that is completed, the next stage is for front end engineers to create patches
+which implement the new UI. Those patches should already contain the `copy` and
+place the strings in the localization resources for the source locale (`en-US`).
+
+The developer is using the localization API by selecting a special identifier we call
+`L10n ID` and optionally a list of variables that will be passed to the translation.
+
+We call this "a social contract" which binds the l10n-id/args combination to a particular
+source translation and use in the UI.
+
+The localizer expects the developer to maintain the contract by ensuring that the
+translation will be used in the given location and way and will correspond to the
+source translation. If that contract is to be changed, the developer will be expected
+to update it. More on that in pkt 6.
+
+The next review comes from either L10n Drivers or experienced front end engineers
+familiar with the internationalization and localization systems making sure that
+the patches are properly using the right APIs and the code is ready to be landed
+into `mozilla-central`.
+
+4) Exposure in `gecko-strings`
+------------------------------
+
+Once the patch land, L10n Drivers will take a final look at localizability of the
+introduced strings and expose them to localizers, who get notified about new
+translation requests.
+
+5) Localization
+---------------
+
+From that moment localizers will work on providing translations for the new feature
+either while the new strings are only in Nightly or after they are merged to Beta.
+The goal is to have as much of the UI ready in as many locales as early as possible,
+but that process is continous and we're capable of releasing Firefox with incomplete
+translations falling back on a backup locale in case of a missing string.
+
+L10n Drivers team is maintaining the status of each locale and deciding whether
+it is ready to be released.
+
+6) String updates
+-----------------
+
+If later in the software engineering life cycle the need arises to update or remove
+the string, the l10n review comes again.
+
+If it's just a string removal, all the engineer has to do is to remove it from the UI
+and from the localization resource file in `mozilla-central`.
+
+If it's an update, we currently have two "levels" of change severity:
+
+1) If the change is minor, like a spelling or punctuation, the developer should update
+the `en-US` translation.
+2) If the change is anyhow affecting the meaning or tone of the message, the developer
+is requested to update the l10n string ID.
+
+The latter is considered a change in the social contract between the developer and
+the localizer and an update to the ID is expected.
+
+The new ID will be recognized by the l10n tooling as untranslated, and the old one
+as obsolete. This will give the localizer oportunnity to find and update the translation.
+
+We're currently evaluating a way to separate out two classes of contract changes,
+one `minor`, which would not invalidate the translation, but flag it for an update, and
+the other, `major`, which would continue invalidating the translation and requiring
+L10n ID changes.
+
+Localization Systems
+====================
+
+Gecko has three main localization systems used. Two older ones, and one
+being currently introduced with an intention of replacing the previous two.
+
+DTD & StringBundle
+==================
+
+DTD is primarely used for XUL and XHTML file localization. It uses `.dtd` files
+and the only localization feature it provides is ability to reference one
+string from another via entity reference.
+
+StringBundle is a runtime API used primarely for localization of the JS code.
+The messages are stored in `.properties` files and loaded via the StringBundle API
+and then retrieved from there via imperative calls.
+
+The system provides external arguments which can be placed into the string, and
+support basic plural categories via a proprietary API `PluralForms.jsm`.
+
+Fluent
+======
+
+Fluent is a modern localization system designed by Mozilla to address the challenges
+of using the old systems.
+
+It's well suited for modern web development cycle, provides a number of localization
+features including good internationalization model and strong bidirectionality support.
+
+Fluent strictly superseeds the old systems and is currently being slowly introduced to
+Firefox and all other Mozilla products with an intent to end up being the only
+unified localization system at Mozilla and a foundation of the future localization
+standard.
+
+To learn more about Fluent, follow the `Fluent for Firefox Developers` guide.