Pootle Documentation¶

Requesting features¶

Sometimes Pootle doesn’t quite meet your expectations or you have an idea for a great new feature.

It might help to understand how Pootle developers evaluate new features:

1. Is it generally useful? i.e. will it be useful for a large number of people?
2. Does it follow the ethos of Pootle? e.g. does it keep the interface clean, is it intuitive and non-technical?
3. How long would it take to implement?
   1. Does it require fundamental changes to how Pootle works? i.e. long, or
   2. Is this just a simple change of layout or a simple feature? i.e. short
4. Is this something a developer is passionate about? Does this meet their itch or are they convinced it is a winning feature?

Reporting bugs¶

In order to best solve the problem we need good bug reports. Reports that do not give a full picture or which coders are unable to reproduce, end up wasting a lot of time. If you, the expert in your bug, spend a bit of time you can make sure your bug gets fixed.

First see if the bug is not already reported. Perhaps someone already reported it and you can provide some extra information in that bug report. You can also add yourself in the CC field so that you get notified of any changes to the bug report.

If you could not find the bug, you should report it. Look through each of the following sections and make sure you have given the information required.

Suggesting doesn't work

In a translation project with proper permissions when I try to suggest I
get a 404 error.

Translating¶

Pootle’s User Interface translations are kept in the official Pootle server. If you have a user in that server, you can start translating right away. Otherwise, just create a new user and start translating.

If your language already has a translation and you want to further improve or complete it, you can contribute suggestions that will later be reviewed by the language administrators.

If you can’t find your language and want to have that added or have concerns of any other means, contact us on our mailing list or on IRC.

Although desirable, it’s not mandatory to use the official Pootle server to translate Pootle itself. In case you feel more comfortable working with files and offline tools, just head to the code repository at GitHub, create your localization based on the latest template and submit it to us by opening a bug or by sending us a pull request.

Documentation¶

You can help us documenting Pootle by just mentioning typos, providing reworded alternatives or by writing full sections.

Pootle’s documentation is written using reStructuredText and Sphinx.

If you intend to build the documentation yourself (it’s converted from reST to HTML using Sphinx), you may want to setup a development environment for that.

Before doing anything¶

Before starting any actual work on the source code, make sure that:

• There is nobody working on the bug you are trying to fix. See the existing bug reports and the existing pull requests. In the situation where somebody else is working on a fix, you can always offer your help.
• If you plan to develop a new feature and want to include it upstream, please first discuss it with the developers on IRC or in the translate-pootle mailing list so that it doesn’t interfere in current development plans. Also note that adding new features is relatively easy, but keeping them updated is harder.

Setting up the development environment¶

The minimum software packages you need for setting up a development environment include git and a Python interpreter along with the pip installer. Consult the specifics for your operating system in order to get each package installed successfully.

Once you have the basic requirements in place, you will need to install Pootle’s dependencies, which come in shape of Python packages. Instead of installing them system-wide, we recommend using virtualenv (and virtualenvwrapper for easing the management of multiple virtualenvs). This way you can install all the dependencies at specific versions without interfering with system-wide packages. You can test on different Python/Django versions in parallel as well.

$ sudo pip install virtualenvwrapper

$ export WORKON_HOME=~/envs
$ mkdir -p $WORKON_HOME
$ source /usr/local/bin/virtualenvwrapper.sh  # Or /usr/bin/virtualenvwrapper.sh

$ mkvirtualenv <env-name>

(env-name) $ deactivate

$ workon <env-name>

(env-name) $ git clone https://github.com/translate/pootle.git

(env-name) $ cd pootle
(env-name) $ pip install -r requirements/dev.txt

(env-name) $ pip install -e .

(env-name) $ cp pootle/settings/90-dev-local.conf.sample pootle/settings/90-dev-local.conf

(env-name) $ python manage.py migrate
(env-name) $ python manage.py initdb

(env-name) $ python manage.py runserver

Workflow¶

Any time you want to fix a bug or work on a new feature, create a new local branch:

$ git checkout -b <my_new_branch>

Then safely work there, create the needed commits and once the work is ready for being incorporated upstream, either:

• Push the changes to your own GitHub fork and send us a pull request, or
• Create a patch against the HEAD of the master branch using git diff or git format-patch and attach it to the affected issue.

Commits¶

When creating commits take into account the following:

What to commit

As far as possible, try to commit individual changes in individual commits. Where different changes depend on each other, but are related to different parts of a problem / solution, try to commit them in quick succession.

If a change in the code requires some change in the documentation then all those changes must be in the same commit.

If code and documentation changes are unrelated then it is recommended to put them in separate commits, despite that sometimes it is acceptable to mix those changes in the same commit, for example cleanups changes both in code and documentation.

Commit messages

Begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough (and sometimes optional) description.

Cleanups

Another example:

Factor out common behavior for whatever

These reduces lines of code to maintain, and eases a lot the maintenance
work.

Also was partially reworked to ease extending it in the future.

If your change fixes a bug in the tracker, mention the bug number. This way the bug is automatically closed after merging the commit.

Docs: Update code for this thing

Now the docs are exact and represent the actual behavior introduced in
commits ef4517ab and abc361fd.

Fixes #2399

If you are reverting a previous commit, mention the sha1 revision that is being reverted.

Revert "Fabric: Cleanup to use the new setup command"

This reverts commit 5c54bd4.

Setting Things Up¶

In order to setup the front-end development enviroment, it’s necessary to have Node.js installed. Please check the installation instructions for your OS.

Once Node.js is available, Pootle dependencies need to be installed.

$ cd pootle/static/js
$ npm install

This will read the package.json file and install the development dependencies.

Building Scripts¶

Simply run:

(env) $ ./manage.py webpack --dev

This will make sure to build all the necessary scripts and create the relevant bundles with source maps support. It will also watch for changes in scripts so you don’t need to constantly be running this.

For creating a production-ready build, use:

(env) $ ./manage.py webpack

This will also run the output through UglifyJS, making the output build considerably lighter in size.

Note that this step is also done as part of the make assets command, so you may only want to run the latter.

Customizing templates¶

In case you need to change a template, copy it into your custom TEMPLATE_DIRS with the same path name as it had before.

You can customize specific blocks of templates by indicating which template the current template is customizing. Use the {% overextends %} template tag for that (requires to install the django-overextends package). This must be the first tag in the template.

{% overextends 'browser/overview.html' %}

{% block pre_content %}
{{ block.super }}
<h1>My custom content</h1>
{% endblock %}

Check the original templates in order to know which blocks can be customized.

On upgrades, you will want to check if the templates and the contained blocks differ.

Customizing JavaScript¶

You can place any custom scripts in your custom STATICFILES_DIRS directory and make them part of the default Pootle bundles by adding a very simple manifest.json file under the js/ directory of your custom STATICFILES_DIRS.

This file must contain an object of key-values where the keys correspond to the entry points defined by Pootle and the values are arrays of module names to include in the output bundle. Check out the pootle/static/js/webpack.config.js file to see the existing entry points.

Example:

{
  "common": ["login.js", "extra_module.js"]
}

In the example above, the login.js and the extra_module.js JavaScript modules will be added as part of the common bundle. If common didn’t exist as an entry point before, a new bundle will be output.

Note that the manifest.json file has to be valid JSON, otherwise it will be omitted.

Custom scripts can require() Pootle modules that are part of the core bundles by prefixing paths with pootle/. For instance the require('pootle/models') call will make Pootle’s own models module available in the scope of a 3rd party script.

Needless to say, you can refer to your custom scripts the same way as you would refer to any other static asset, i.e. by using the {% static %} template tag.

Customizing CSS¶

Create any needed files under your custom STATICFILES_DIRS and reference them from your custom templates using the {% static %} template tag. You can also inline styles in your templates as usual.

Customizing images¶

You should put your custom images in your custom STATICFILES_DIRS. From CSS you would just reference them using a relative path.

On the contrary, if you want to reference images from HTML code or inline CSS, you should use the {% static %} template tag.

Installing JS build libraries¶

Before you can rebuild your static assets with any CSS or JavaScript customisations, you will need to install some Node.js libraries.

Before proceeding please make sure you have Node.js and npm installed in your system.

(env) $ cd $pootle_dir
(env) $ cd pootle/static/js/
(env) $ npm install

$pootle_dir is the directory where Pootle is installed.

Rebuilding assets after customization¶

Before rebuilding your assets for the first time you must install the JavaScript build libraries.

After doing any customizations, you will need to regenerate any modified bundles and gather all the static assets in a single place for public consumption.

You will need to activate your virtual environment before running these commands.

(env) $ pootle webpack
(env) $ pootle collectstatic --noinput --clear -i node_modules -i *.jsx
(env) $ pootle assets build

Settings for Tests¶

Some testing-specific settings are loaded from the tests/settings.py file and override any previous setting you might have set in the settings/*.conf files.

Writing Tests¶

Writing new tests is easy. Just write a function whose name starts with test_ and place it in an appropriate module under the tests/ subdirectory.

You’ll need to use plain Python assertions in test functions. Check pytest’s documentation for more information on assertions.

In order to use a fixture, you simply need to reference its name as a function argument. Pytest does the rest of the magic. There are other ways to reference and use fixtures as well, but most of the time you’ll find yourself passing them as function arguments.

Fixtures¶

Pootle tests include some pytest fixtures you can reuse. They’re located in tests/fixtures/ and are loaded when the test runner is being set up.

If you have a fixture which is very specific you can place it in a usual conftest.py file in its proper context, whereas the aforementioned directory is meant to be for storing shared or general-purpose fixtures.

Principles¶

• Align Pootle releases with Django releases, keeping compatibility with the latest version of the framework and avoiding the use, and maintenance headache, of deprecated code.
• Time-based feature releases every six months, this ensures that users, who don’t want to run from master, and packagers have regular features updates.
• Master is always stable, this ensures that anyone can run a production server from master. It also reduces our effort of maintaining multiple branches in development. Lastly, it helps create a discipline of landing stable features.

Rules¶

The principles above extended into these rules.

1. Feature releases are made every six months.
2. Feature releases (as distinct from a bug fix release) are only against the latest Django version that Pootle supports i.e. we won’t backport features.
3. Security fixes are made to the last two time-based releases.
4. Older time-based releases are no longer supported.
5. Pootle should run on Django N and N-1.
6. master is always releasable.
7. All schema related and major changes are made in feature branches.
8. One month before a time-based release, when master is in a stabilising period, schema and feature changes should not landed on master.

Version Numbering¶

A Pootle version number consists of Major-Minor-Point-Bugfix as in 2.5.0 or 2.6.1.2

Pootle’s minor number is changed to indicate the latest version of Django that is supported. Thus when the latest version of Django is released, and Pootle gains support for this version, then the Pootle minor number will change.

Every six months, when a new release train is ready to be shipped, Pootle’s point version will be incremented.

Any critical security fixes will automatically result in a new bugfix release.

Examples¶

Understanding the number and release train with some examples:

Django 1.5 is the latest version of Django:

• Pootle is named 2.5 and should support Django 1.5.
• Pootle 2.5.0 is released as the first time-based release.
• Next time-based release would be 2.5.1.

A security issue is detected in Pootle 2.5.0

• The first security release 2.5.0.1 is made
• Next time-based release is still 2.5.1

Django 1.6 is released:

• Current Pootle release is 2.5.4, next Pootle release will be 2.6.0
• When 2.6.0 is out we will support Pootle 2.6.0 and 2.5.4, all previous versions will be unsupported.

A security issue is discovered which impacts all our supported time-based releases:

• We release 2.6.0.1 and 2.5.4.1

Time-based release 2.6.1 is released six months after 2.6.0

• We now support 2.6.1 and 2.6.0
• Support is dropped for 2.5.4 which is now a year old.

The Release Train: Point Releases Every Six Months¶

Within the priciple that master is always deployable we aim to ensure a period of stability to allow easier release in the month prior to a time-based release.

First-Fifth month

All major work and features are allowed, strings may be broken.

Sixth month

Feature work that doesn’t change the DB schema, bug fixes, refinements and translations. Strings are frozen.

If for some reason there’s feature work that changes the schema during month six of the release train, the feature will go in its own branch and won’t be merged until the next release train starts.

Security fixes are applied anytime in the release train.

Branching Strategy¶

The next Pootle version is always baked in the master branch. Exceptions are security fixes which are committed in master and cherry-picked to the currently supported time-based release branches.

A new time-based release is made off of master, incrementing the point version. Every time a new release happens, a new branch is created. These branches are named after their version numbers: if master is to become version 2.6.2, then the new branch will be named stable/2.6.2. The actual release is also tagged, in this case as 2.6.2.

Security fixes are made on the relevant release branches. So the first security release on stable/2.6.2 would be tagged as 2.6.2.1.

Features that produce schema changes or are quite invasive go into feature branches named feature/<feature-name>. Once the feature is ready to be integrated within the first phase of the release train, they’re merged into master.

Translation States¶

Untranslated

A unit that is not translated i.e. blank.

Incomplete

See: Needs Attention i.e. Untranslated + Fuzzy

Translated

The unit has a translation.

Fuzzy

In Gettext PO fuzzy means that a unit will needs to be reviewed and will not be used in production. On Pootle for the user we call this ‘Needs Work’ as the term fuzzy is either technical for some users, or confusing to those who use the term fuzzy for Translation Memory, as in ‘fuzzy match’.

Needs work

See: Fuzzy

Needs review

Currently see: Fuzzy In the future this will actually mean that the translated string still requires review.

Needs attention

Untranslated + Fuzzy

Pootle internals¶

Context object (ctx_obj)

An object representing the context that encloses the current view.

If we are navigating through the files for an existing translation project, the context object will refer to the current translation project.

Similarly, if we are in the overview page for a language, the context will point to the current language object. In the overview page for a project, the context object points to the current project.

At a higher level, the root directory is considered the context object.

Resource object (resource_obj)

An object representing the resource that the current view is referring to.

For example, if we are navigating through the files and directories for an existing translation project, the resource object will refer to the current file or directory object.

If the current view refers to multiple resources, the resource object is the same as the context object.

Python and documentation¶

For Python code and documentation Pootle follows the Translate Styleguide adding extra clarifications listed below.

• Python style conventions
• Documentation style conventions

import re
import sys.path as sys_path
import time
from datetime import timedelta
from os import path

from lxml.html import fromstring
from translate.storage import versioncontrol

from django.contrib.sites.models import Site
from django.db import models
from django.db.models import Q
from django.db.models.signals import post_save

from tastypie.models import ApiKey

from pootle_language.models import Language
from pootle_translationproject.models import TranslationProject

from .forms import GoalForm
from .models import Tag

class SampleForm(forms.Form):
    # Field declaration that spans to several lines.
    language = forms.ChoiceField(
        label=_('Interface Language'),
        initial="",
        required=False,
        widget=forms.Select(attrs={
            'class': 'js-select2 select2-language',
        }),
        help_text=_('Default language for using on the user interface.'),
    )
    # One line field declaration.
    project = forms.ModelChoiceField(Project, required=True)

urlpatterns = patterns('pootle_project.views',
    # Listing of all projects.
    url(r'^$',
        'projects_index'),

    # Whatever URLs.
    url(r'^incredibly-stupid/randomly-long-url-with-hyphens-that-is-split-'
        r'and-continued-on-next-line.html$',
        'whatever',
        name='pootle-project-whatever'),

    # Admin URLs.
    url(r'^(?P<project_code>[^/]*)/admin.html$',
        'project_admin'),
    url(r'^(?P<project_code>[^/]*)/permissions.html$',
        'project_admin_permissions',
        name='pootle-project-admin-permissions'),
)

JavaScript¶

Follow the great Airbnb JavaScript Style Guide. Go check it out for all the details.

As a summary, that includes:

• 2-space indent.
• Single quotes.
• pascalCase variable naming.

In addition to that:

• Try to be in the 80 (+4) soft character limit, but be wise to know when to make exceptions.
• Use ES2015.
• Avoid jQuery.

When dealing with existing or legacy code, also keep in mind to:

• Prefix with $ Variables holding jQuery objects.
• Use js- to prefix selectors for elements queried via JavaScript.

HTML¶

Indenting

• Indent using 2 spaces. Don’t use tabs.
• Although it’s desirable to avoid lines longer than 80 characters, most of the time the templating library doesn’t easily allow this. So try not to extend too much the line length.

Template naming

• If a template name consists on several words they must be joined using underscores (never hyphens), e.g. my_precious_template.html
• If a template is being used in AJAX views, even if it is also used for including it on other templates, the first word on its name must be xhr, e.g. xhr_tag_form.html.
• If a template is intended to be included by other templates, and it is not going to be used directly, start its name with an underscore, e.g. _included_template.html.

Quoting

• Always use double quotes for HTML attribute values.

• Always use single quotes for Django template tags and template filters located inside HTML attribute values.

  <!-- Good -->
  <a href="{% url 'whatever' %}" class="highlight">
  
  
  
  <!-- Bad -->
  <a href="{% url "whatever" %}" class="highlight">
  <a href='{% url 'whatever' %}' class='highlight'>
  <a href='{% url "whatever" %}' class='highlight'>
  

CSS¶

Indenting

• Indent using 4 spaces. Don’t use tabs.
• Put selectors and braces on their own lines.

Good:

.foo-bar,
.foo-bar:hover
{
    background-color: #eee;
}

Bad:

.foo-bar, .foo-bar:hover {
  background-color: #eee;
}

Naming

• Selectors should all be in lowercase and consequent words should be separated using dashes. As an example, rather use .tm-results and not .TM_results.

The “rules” of deprecation¶

So some rough “rules”. These apply to features, management commands and settings.

1. If it’s not released. Drop it and tell others on #pootle-dev. If it has settings add them to the settings deprecation infrastructure to force removal if required.
2. If it is obsolete or replaced with an equivalent then drop with no fanfare and add settings to the deprecation infrastructure so that an admin will remove settings from their settings files. Add to release notes if needed.
3. If it has been renamed. Put that in the release notes and allow fallback for one version. Use deprecation infrastructure for settings to allow old settings to continue to work until the N+1 release. After that its a hard failure. For commands simply rename.
4. If things changed. For settings put that in release notes and do a hard failure to ensure that admins will reconfigure. For commands, just put those notes in the release notes and in the command features.
5. If removed. Put in release notes. For settings choose either hard or soft failure depending on whether something needs to be done by the admin. Put in release notes together with a guide on how to work around the missing feature if its possible. for commands simply make sure they are highlighted as removed in the release notes.

Implementing a deprecated setting¶

1. Add the newly deprecated setting to pootle/core/utils/deprecation.py DEPRECATIONS.
2. Move the deprecated setting to the deprecated section in the settings document. With the needed .. deprecated:: N.M marker.
3. Add to the release notes.

Pre-release tasks¶

Before starting the release process it is necessary to perform some previous tasks.

Create the package¶

The first steps are to create and validate a package for the next release.

$ git clone git@github.com:translate/pootle.git pootle-release
$ cd pootle-release
$ git submodule update --init

$ git grep 2013  # Should pick up anything that should be examined

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""Configuration file to build Pootle.

Must be placed in ~/.pootle/pootle_build.conf
"""

# Django now requires to set some secret key to be set.
SECRET_KEY = '__BuildingPootle_1234567890__'

# Silence some checks so the build output is cleaner.
SILENCED_SYSTEM_CHECKS = [
    'pootle.W004',  # Pootle requires a working mail server
    'pootle.W006',  # sqlite database backend is unsupported
    'pootle.W010',  # DEFAULT_FROM_EMAIL has default setting
    'pootle.W011',  # POOTLE_CONTACT_EMAIL has default setting
]

$ mkvirtualenv build-checks-templates
(build-checks-templates)$ pip install -r requirements/build.txt
(build-checks-templates)$ export POOTLE_SETTINGS=~/.pootle/pootle_build.conf
(build-checks-templates)$ DJANGO_SETTINGS_MODULE=pootle.settings ./setup.py build_checks_templates
(build-checks-templates)$ deactivate
$ unset POOTLE_SETTINGS
$ rmvirtualenv build-checks-templates

$ git log $previous_version..HEAD > docs/releases/$version.rst

$ git log 2.5.0..HEAD > docs/releases/2.5.1.rst

$ git log 2.5.0..HEAD --format='%aN, ' | awk '{arr[$0]++} END{for (i in arr){print arr[i], i;}}' | sort -rn | cut -d\  -f2-

(major, minor, micro, candidate, extra)

(1, 10, 0, 'final', 0)
(2, 7, 0 'alpha', 1)

$ mkvirtualenv build-pootle-release
(build-pootle-release)$ pip install -r requirements/build.txt
(build-pootle-release)$ export PYTHONPATH="${PYTHONPATH}:`pwd`"
(build-pootle-release)$ export POOTLE_SETTINGS=~/.pootle/pootle_build.conf
(build-pootle-release)$ cd pootle/static/js && npm install && cd ../../../
(build-pootle-release)$ make mo-all  # If we are shipping an RC
(build-pootle-release)$ make build
(build-pootle-release)$ deactivate
$ unset POOTLE_SETTINGS
$ rmvirtualenv build-pootle-release

$ mkvirtualenv test-pootle-release
(test-pootle-release)$ pip install dist/Pootle-$version.tar.bz2
(test-pootle-release)$ pip install MySQL-python
(test-pootle-release)$ pootle init

(test-pootle-release)$ deactivate
$ rmvirtualenv test-pootle-release

Publish the new release¶

Once we have a valid package it is necessary to publish it and announce the release.

$ git checkout -b stable/2.6.0
$ git push origin stable/2.6.0
$ git tag -a 2.6.0 -m "Tag version 2.6.0"
$ git push --tags

$ ./setup.py register

$ make publish-pypi

$ git checkout gh-pages

Post-Releasing Tasks¶

These are tasks not directly related to the releasing, but that are nevertheless completely necessary.

2.7.6 vs 2.7.5¶

Changes since 2.7.5:

• Fixed assets

View the git log for complete information.

Credits¶

This release was made possible by the following people:

Leandro Regueiro.

And to all our bug finders, testers and translators, a Very BIG Thank You.

2.7.5 vs 2.7.4¶

Changes since 2.7.4:

• Fixed build process
• Expanded list or RTL languages

View the git log for complete information.

Credits¶

This release was made possible by the following people:

Leandro Regueiro, Dwayne Bailey, Ryan Northey, Jason P. Pickering.

And to all our bug finders, testers and translators, a Very BIG Thank You.

2.7.4 vs 2.7.3¶

Changes since 2.7.3:

• Updated some requirements to prevent failures on rebuilding assets.
• Requirements use ranges to prevent installing broken versions (issue 4737)

View the git log for complete information.

Credits¶

This release was made possible by the following people:

Leandro Regueiro, Taras Semenenko, Mikhail Paulyshka, Dwayne Bailey.

And to all our bug finders, testers and translators, a Very BIG Thank You.

2.7.3 vs 2.7.3b1¶

Changes since 2.7.3b1:

• Several critical security fixes that prevent potential XSS attacks

Major Changes¶

• Several critical security fixes that prevent potential XSS attacks
• Pootle no longer supports the MySQL’s MyISAM database backend, users are strongly encouraged to convert their database to InnoDB.
• The editor for static pages now highlights the content’s markup and displays a live preview.
• Added support for Elasticsearch-based external Translation Memory servers.
• Changed connection logic and added checks for misconfigured Translation Memory servers.
• Significant speed up when importing files.

Below we provide much more detail. These are by no means exhaustive, view the git log for complete information.

Changes not reported on previous releases¶

There are some changes that haven’t being reported on their corresponding release notes at the time:

• In release 2.7.0 support was dropped for allowing to allow users to specify their preferred UI language on Pootle. Pootle now uses the preferred languages as reported by the user’s browser and falls back to English if the specified languages can’t be used. See Setting language preferences in a browse for more information. The ability to specify Pootle UI language will be added back (issue 4230).

Details of changes¶

• Several critical security fixes that prevent potential XSS attacks
• Store update has been refactored which has brought a significant speed up when importing files.
• Static pages and announcements:
  • The editor for static pages now highlights the content’s markup and displays a live preview of the rendered contents (issue 3346, issue 3766).
  • Project and language announcements are now also displayed on their respective overview pages.
• Translation memory:
  • update_tmserver:
    • Renamed --overwrite to --refresh.
    • Translations from disabled projects must be explicitly included with --include-disabled-projects.
    • Added support for Elasticsearch-based external Translation Memory servers, which can be populated from translation files or directories on disk. This effectively brings the ability to display TM results from different TM servers, sorting them by their score.
    • Translations saved from Pootle now include a timestamp.
    • Fixed missing index error issue 4120.
  • POOTLE_TM_SERVER:
    • The default TM server has been renamed to local. Make sure to adjust your settings.
    • Added a new WEIGHT option to raise or lower the TM results score for each specific TM server.
    • Added several checks to ensure this setting is not misconfigured.
  • Changed connection logic for Translation Memory servers to handle connection issues and misconfigurations on the settings.
• Database:
  • InnoDB is the supported MySQL backend. Deployments using MyISAM must migrate to either MySQL (InnoDB) or PostgreSQL.
  • Close a database connection before and after each rqworker job once it. exceeds the maximum age to imitate Django’s request/response cycle issue 4094.
• Editor:
  • Non-critical checks can once again be muted/unmuted.
  • Fixed units sorting issue for admin users issue 4116.
• Import/export and upload/download:
  • Fixed running export command without options.
  • Added a new --user to import to attribute changes to specified user on file import.
  • Ignore non project filetypes when uploading zip files issue 4124.
  • Only authenticated users with translate rights can upload translations.
  • Any authenticated user can now download translations.
  • Translations from Terminology project can now also be downloaded.
• initdb:
  • Now has an --no-projects option to prevent creating the default projects at set up.
  • Now loads the translations for the default projects and languages and triggers their stats calculation.
  • Doesn’t throw errors when accidentally being run more than once.
• The Apertium MT backend has been dropped.
• Report string errors form subject and body can be overriden.
• Language managers can now edit their language’s special characters by using the Special Characters page accessible through the browse dropdown in the language overview page.
• Added extra data to reports.
• Added more languages for Yandex machine translation.
• Fixed test_checks errors when being run with no options and without the :option:` –check` option.
• Pulled latest translations.

...and lots of refactoring, new tests, cleanups, improved documentation and of course, loads of bugs were fixed.

Credits¶

This release was made possible by the following people:

Julen Ruiz Aizpuru, Leandro Regueiro, Ryan Northey, Dwayne Bailey, Taras Semenenko.

And to all our bug finders, testers and translators, a Very BIG Thank You.

Major Changes¶

• MySQL’s MyISAM support has been dropped. Use InnoDB instead.
• The editor for static pages now highlights the content’s markup and displays a live preview.
• Added support for Elasticsearch-based external Translation Memory servers.
• Changed connection logic and added checks for misconfigured Translation Memory servers.
• Significant speed up when importing files.

Below we provide much more detail. These are by no means exhaustive, view the git log for complete information.

Changes not reported on previous releases¶

There are some changes that haven’t being reported on their corresponding release notes at the time:

• In release 2.7.0 support was dropped for allowing to allow users to specify their preferred UI language on Pootle. Pootle now uses the preferred languages as reported by the user’s browser and falls back to English if the specified languages can’t be used. See Setting language preferences in a browse for more information. The ability to specify Pootle UI language will be added back (issue 4230).

Details of changes¶

• Pulled latest translations.
• Store update has been refactored which has brought a significant speed up when importing files.
• Static pages and announcements:
  • The editor for static pages now highlights the content’s markup and displays a live preview of the rendered contents (issue 3346, issue 3766).
  • Project and language announcements are now also displayed on their respective overview pages.
• Translation memory:
  • update_tmserver:
    • Renamed --overwrite to --refresh.
    • Translations from disabled projects must be explicitly included with --include-disabled-projects.
    • Added support for Elasticsearch-based external Translation Memory servers, which can be populated from translation files or directories on disk. This effectively brings the ability to display TM results from different TM servers, sorting them by their score.
    • Translations saved from Pootle now include a timestamp.
    • Fixed missing index error issue 4120.
  • POOTLE_TM_SERVER:
    • The default TM server has been renamed to local. Make sure to adjust your settings.
    • Added a new WEIGHT option to raise or lower the TM results score for each specific TM server.
    • Added several checks to ensure this setting is not misconfigured.
  • Changed connection logic for Translation Memory servers to handle connection issues and misconfigurations on the settings.
• Database:
  • InnoDB is the only accepted MySQL backend. Deployments using MyISAM must migrate to either MySQL (InnoDB) or PostgreSQL.
  • Close a database connection before and after each rqworker job once it. exceeds the maximum age to imitate Django’s request/response cycle issue 4094.
• Editor:
  • Non-critical checks can once again be muted/unmuted.
  • Fixed units sorting issue for admin users issue 4116.
• Import/export and upload/download:
  • Fixed running export command without options.
  • Added a new --user to import to attribute changes to specified user on file import.
  • Ignore non project filetypes when uploading zip files issue 4124.
  • Only authenticated users with translate rights can upload translations.
  • Any authenticated user can now download translations.
  • Translations from Terminology project can now also be downloaded.
• initdb:
  • Now has an --no-projects option to prevent creating the default projects at set up.
  • Now loads the translations for the default projects and languages and triggers their stats calculation.
  • Doesn’t throw errors when accidentally being run more than once.
• The Apertium MT backend has been dropped.
• Report string errors form subject and body can be overriden.
• Language managers can now edit their language’s special characters by using the Special Characters page accessible through the browse dropdown in the language overview page.
• Added extra data to reports.
• Added more languages for Yandex machine translation.
• Fixed test_checks errors when being run with no options and without the :option:` –checks` option.

...and lots of refactoring, new tests, cleanups, improved documentation and of course, loads of bugs were fixed.

Credits¶

This release was made possible by the following people:

Julen Ruiz Aizpuru, Leandro Regueiro, Dwayne Bailey, Ryan Northey, Taras Semenenko.

And to all our bug finders, testers and translators, a Very BIG Thank You.

Changes in Requirements¶

• Django >= 1.7.10, < 1.8
• Translate Toolkit >= 1.13.0
• Python >= 2.7, < 3.0
• Redis >= 2.8.4
• Django transaction hooks
• Unix-based operating system.

Major Changes¶

• Bugfixes for some important issues.
• Pulled latest translations.

Below we provide much more detail. These are by no means exhaustive, view the git log for complete information.

Details of changes¶

• Prevent local TM from crashing if elasticsearch is unavailable. elasticsearch version must now be 1.6.0 at most.
• Prevent regular users from seeing disabled projects translation stats.
• If disabled, do not the display contact form on sign in and sign up.
• Fixed regression for admin users on export view.
• Fixed issue with translatable extraction tools that prevented several texts from being translated.
• Pulled latest translations.

...and cleanups, improved documentation.

Credits¶

This release was made possible by the following people:

Dwayne Bailey, Leandro Regueiro, Julen Ruiz Aizpuru, Ryan Northey, Taras Semenenko.

And to all our bug finders, testers and translators, a Very BIG Thank You.

Changes in Requirements¶

• Django >= 1.7.10, < 1.8
• Translate Toolkit >= 1.13.0
• Python >= 2.7, < 3.0
• Redis >= 2.8.4
• Django transaction hooks
• Unix-based operating system.

Major Changes¶

• Updated translations.
• Added django-transaction-hooks
• Changed user delete behaviour
• Lots of command changes and additions
• Improved upload

Below we provide much more detail. These are by no means exhaustive, view the git log for complete information.

Details of changes¶

Credits¶

This release was made possible by the following people:

Julen Ruiz Aizpuru, Ryan Northey, Taras Semenenko, Leandro Regueiro, Dwayne Bailey, Jerome Leclanche, Kevin Scannell, Daniel Widerin.

And to all our bug finders, testers and translators, a Very BIG Thank You.

Changes in Requirements¶

• Django >= 1.7, < 1.8
• Translate Toolkit >= 1.13.0
• Python >= 2.7, < 3.0
• Redis >= 2.8
• Unix-based operating system.

Major Changes¶

• Switched license from GPLv2 to GPLv3.
• The Evernote Pootle fork and Translate Pootle are now merged into the same code base and are being actively developed together.
• Major UI revamp - browsing pages are consistent across all views. Navigation is now much easier, more consistent and more powerful. The editor is cleaner and works to prevent errors early.
• Backgrounding statistics calculations - so Pootle and its users are never bogged down or delayed by real time stats calculations. Instead these are backgrounded and updated when available.
• A number of features have been removed and will be recovered in future releases.

Below we provide much more detail. These are by no means exhaustive, view the git log for complete information.

Details of changes¶