<commit_before>============
Contributing
============

Bugs
====

All bugs are tracked in `<https://bugzilla.mozilla.org/>`_.

Write up a new bug:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools&component=Pontoon


Docker
======

Everything runs in a Docker container. Thus Pontoon requires fewer things to get
started and you're guaranteed to have the same setup as everyone else and it
solves some other problems, too.

If you're not familiar with `Docker <https://docs.docker.com/>`_ and
`docker-compose <https://docs.docker.com/compose/overview/>`_, it's worth
reading up on.


Database
========

By default, you will have default data loaded for only the Pontoon Intro project.
If you have a database dump, you can load it into your PostgreSQL database.

Make sure you backup your existing database first:

.. code-block:: shell

    $ make dumpdb

And then load the dump:

.. code-block:: shell

    $ make loaddb DB_DUMP_FILE=path/to/my/dump

Note that your database container needs to be running while you do that. You
can start just the postgresql container by running:

.. code-block:: shell

    $ docker-compose run postgresql -d


Interactive shell
=================

If you need to run specific commands, that are not covered by our `Makefile`,
you can start an interactive shell inside a Pontoon container:

.. code-block:: shell

    $ make shell


Browser Support
===============

The following is the `browser support matrix of Pontoon <https://browserl.ist/?q=Firefox+%3E%3D+52%2C+FirefoxAndroid+%3E%3D+52%2C+Chrome+%3E%3D+55%2C+ChromeAndroid+%3E%3D+55%2C+Edge+%3E%3D+15%2C+Safari+%3E%3D+10.1%2C+iOS+%3E%3D+10.3>`_:

.. code-block:: bash

    Firefox >= 52,
    FirefoxAndroid >= 52,
    Chrome >= 57,
    ChromeAndroid >= 57,
    Edge >= 16,
    Safari >= 10.1,
    iOS >= 10.3


Python code conventions
=======================

Our Python code is automatically formatted using `black <https://black.readthedocs.io/en/stable/>`_.
We enforce that in our Continuous Integration, so you will need to run
black on your code before sending it for review.

You can run black locally either as an
`add-on in your code editor <https://black.readthedocs.io/en/stable/editor_integration.html>`_,
or as a `git pre-hook commit <https://black.readthedocs.io/en/stable/version_control_integration.html>`_.
Alternatively, you can format your code using:

.. code-block:: shell

    $ make black

.. note::

    Using black on all Python code means that we cannot fight over code style anymore.
    You are free to write code however you like, because in the end black is the one
    that will format it. We thus don't need to pay any more attention to style during
    code reviews, and are free from those never-ending code style discussions.

Additionally, we use a linter to verify that imports are correct. You can run it with:

.. code-block:: shell

    $ make flake8

In the rare case when you cannot fix a flake8 error, use ``# noqa`` to make the linter
ignore that error. Note that in most cases, it is better to fix the issues than ignoring them.


Javascript code conventions
===========================

Outside the ``frontend`` folder, we don't follow strict rules other than using
2-space indentation.

Inside ``frontend`` (which contains the Translate app), our code is formatted using `Prettier <https://prettier.io/docs/en/index.html>_`.
We enforce that in our Continuous Integration, so you will need to run
prettier on your code before sending it for review.

You can run prettier locally either as an
`add-on in your code editor <https://prettier.io/docs/en/editors.html>`_,
or as a `git pre-hook commit <https://prettier.io/docs/en/precommit.html>`_.
Alternatively, you can format your code using:

.. code-block:: shell

    $ make prettier 

Additioanally, there are linting rules that are defined in our
``.eslintrc.js`` file.

To run the linter, do:

.. code-block:: shell

    $ make lint-frontend

For more specifics about the ```frontend`` folder, look at the README.md file there.


.. A note about formatting...::

    To format both the frontend and Python code at once you can use:

    .. code-block:: shell

        $ make format


Git conventions
===============<commit_msg>Update section about code formatting (#1859)<commit_after>============
Contributing
============

Bugs
====

All bugs are tracked in `<https://bugzilla.mozilla.org/>`_.

Write up a new bug:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools&component=Pontoon


Docker
======

Everything runs in a Docker container. Thus Pontoon requires fewer things to get
started and you're guaranteed to have the same setup as everyone else and it
solves some other problems, too.

If you're not familiar with `Docker <https://docs.docker.com/>`_ and
`docker-compose <https://docs.docker.com/compose/overview/>`_, it's worth
reading up on.


Database
========

By default, you will have default data loaded for only the Pontoon Intro project.
If you have a database dump, you can load it into your PostgreSQL database.

Make sure you backup your existing database first:

.. code-block:: shell

    $ make dumpdb

And then load the dump:

.. code-block:: shell

    $ make loaddb DB_DUMP_FILE=path/to/my/dump

Note that your database container needs to be running while you do that. You
can start just the postgresql container by running:

.. code-block:: shell

    $ docker-compose run postgresql -d


Interactive shell
=================

If you need to run specific commands, that are not covered by our `Makefile`,
you can start an interactive shell inside a Pontoon container:

.. code-block:: shell

    $ make shell


Browser Support
===============

The following is the `browser support matrix of Pontoon <https://browserl.ist/?q=Firefox+%3E%3D+52%2C+FirefoxAndroid+%3E%3D+52%2C+Chrome+%3E%3D+55%2C+ChromeAndroid+%3E%3D+55%2C+Edge+%3E%3D+15%2C+Safari+%3E%3D+10.1%2C+iOS+%3E%3D+10.3>`_:

.. code-block:: bash

    Firefox >= 52,
    FirefoxAndroid >= 52,
    Chrome >= 57,
    ChromeAndroid >= 57,
    Edge >= 16,
    Safari >= 10.1,
    iOS >= 10.3


Code style
==========

We use code formatters so that we do not have to fight over code style.
You are free to write code however you like, because in the end the formatter is the one
that will format it. We thus don't need to pay attention to style during
code reviews, and are free from those never-ending code style discussions.

To format the Python and the JavaScript code at once you can use:

.. code-block:: shell

    $ make format

Code formatting is explained in more detail in the following sections.


Python code conventions
=======================

Our Python code is automatically formatted using `black <https://black.readthedocs.io/en/stable/>`_.
We enforce that in our Continuous Integration, so you will need to run
black on your code before sending it for review.

You can run black locally either as an
`add-on in your code editor <https://black.readthedocs.io/en/stable/editor_integration.html>`_,
or as a `git pre-hook commit <https://black.readthedocs.io/en/stable/version_control_integration.html>`_.
Alternatively, you can format your code using:

.. code-block:: shell

    $ make black

Additionally, we use a linter to verify that imports are correct. You can run it with:

.. code-block:: shell

    $ make flake8

In the rare case when you cannot fix a flake8 error, use ``# noqa`` to make the linter
ignore that error. Note that in most cases, it is better to fix the issues than ignoring them.


Javascript code conventions
===========================

Our Javascript code is automatically formatted using `Prettier <https://prettier.io/docs/en/index.html>_`.
We enforce that in our Continuous Integration, so you will need to run
prettier on your code before sending it for review.

You can run prettier locally either as an
`add-on in your code editor <https://prettier.io/docs/en/editors.html>`_,
or as a `git pre-hook commit <https://prettier.io/docs/en/precommit.html>`_.
Alternatively, you can format your code using:

.. code-block:: shell

    $ make prettier 

Additioanally, there are linting rules that are defined in our
``.eslintrc.js`` file. To run the linter, do:

.. code-block:: shell

    $ make lint-frontend

In the rare case when you cannot fix an eslint error, use ``// eslint-disable`` to make the linter
ignore that error. Note that in most cases, it is better to fix the issues than ignore them.

For more specifics about the ```frontend`` folder, look at the README.md file there.


Git conventions
===============
{'fraction_non_alphanumeric': 0.1183826107280589, 'fraction_numerical': 0.013205562697206965, 'mean_word_length': 3.9611594202898552, 'pattern_counts': {'":': 0, '<': 23, '<?xml version=': 0, '>': 37, 'https://': 22, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3255765', 'n_tokens_mistral': 2712, 'n_tokens_neox': 2485, 'n_words': 1078}