msgid "To give the community the best documentation possible, we listed here a few guidelines, tips and tricks that will make your content shine at its brightest! While we encourage you to adopt your own writing style, some rules still apply to give the reader more clarity and comprehension."
msgid "We strongly recommend contributors to carefully read the other documents in this *Contribution* section of the documentation. Good knowledge of the ins and outs of **RST writing** is required to write and submit your contribution. Note that it also affects your writing style itself."
msgid "**Writing for documentation** isn't the same as writing for a blog or another medium. Readers are more likely to skim read until they've found the information they are looking for. Keep in mind that the user documentation is a place to inform and describe, not to convince and promote."
msgid "Make sure that your writing style remains **consistent**. If you modify an existing text, try to match the existing tone and presentation, or rewrite it to match your own style."
msgid "In English, descriptions and instructions require the use of a **Present Tense**, while a *future tense* is appropriate only when a specific event is to happen ulteriorly. This logic might be different in other languages."
msgid "In English, a new idea implies a new paragraph, rather than having a *line break* as it is common to do in some other languages. *Line breaks* are useful for layout purposes but shouldn't be used as a grammatical way of separating ideas."
msgid "Use different **headings levels** to organize your text by sections and sub-sections. Your headings are also displayed in a dynamic *navigation bar* on the side."
msgid "Your *page title* gives your reader a quick and clear understanding of what your content is about. It is also referenced in the section's *table of contents*."
msgid "The *content* in this section describes the upcoming content from a **business point of view**, and shouldn't put the emphasis on Odoo, as this is documentation and not marketing."
msgid "Start first with a **Lead Paragraph**, which helps the reader make sure that they've found the right page, then explain the **business aspects of this topic** in the following paragraphs."
msgid "This first H2 section is about the configuration of the feature, or the prerequisites to achieve a specific goal. To add a path, make sure you use the ``:menuselection:`` specialized directive (see link below)."
msgid "Create as many main sections as you have actions or features to distinguish. The title can start with a verb, but try to avoid using \"Create ...\"."
msgid "Adding a few images to illustrate your text helps the readers to understand and memorize your content. However, avoid adding too many images: it isn't necessary to illustrate all steps and features, and it may overload your page."
msgid "Screenshots are automatically resized to fit the content block's width. This implies that screenshots can't be too wide, else they would appear very small on-screen. Therefore, we recommend to avoid to take screenshots of a full screen display of the app, unless it is relevant to do so."
msgid "**Resize** your browser's width, either by *resizing the window* itself or by opening the *browser's developer tools* (press the ``F12`` key) and resizing the width."
msgid "Resizing the window's width is the most important step to do as Odoo's responsive design automatically resizes all fields to match the window's width."
msgid "An **ALT tag** is a *text alternative* to an image. This text is displayed if the browser fails to render the image. It is also helpful for users who are visually impaired. Finally, it helps search engines, such as Google, to understand what the image is about and index it correctly, which improves the :abbr:`SEO (Search Engine Optimization)` significantly."
msgid "This introductory guide will help you acquire the tools and knowledge you need to write documentation, whether you plan to make a minor content change or document an application from scratch."
msgid "This tutorial only concerns the `user documentation <https://www.odoo.com/documentation/user/index.html>`_ of Odoo. The documentation for `developing in Odoo <https://www.odoo.com/documentation/master/index.html>`_ in maintained alongside the source code of Odoo at `github.com/odoo/odoo <https://github.com/odoo/odoo/tree/master/doc>`_."
msgid "Our documentation is written in **reStructuredText** (RST), a `lightweight markup language <https://en.wikipedia.org/wiki/Lightweight_markup_language>`_ consisting of normal text augmented with markup which allows including headings, images, notes, and so on. This might seem a bit abstract but there is no need to worry. :abbr:`RST (reStructuredText)` is not hard to learn, especially if you intend to make only small changes to the content."
msgid "If you need to learn about a specific markup, head over to :doc:`our cheat sheet for RST <rst_cheat_sheet>` which contains all the information that you should ever need for the user documentation of Odoo."
msgid "We kindly ask you to observe a set of :doc:`content <content_guidelines>` and :doc:`RST <rst_guidelines>` guidelines as you write documentation. This ensures that you stay consistent with the rest of the documentation and facilitates the approval of your content changes as they are reviewed by a redactor at Odoo."
msgid "Now, depending on whether you want to update existing content, or rather work on new content and make file changes, you have two courses of action:"
msgid "**For small changes** in ``.rst`` files only, i.e. addition/edition of paragraphs or typos, **we suggest that you use the GitHub interface**. This is the easiest and fasted way to submit your request for changes for the documentation and is suitable for non-technical people. Read :ref:`contributing/github-interface` to learn how to use this method."
msgid "**For more complex cases**, it is necessary to **use Git and work from a local copy of the documentation**. This method seems intimidating but only requires basic knowledge of Git. See :ref:`contributing/canonical-git-workflow` for more information on this method."
msgid "Verify that you are browsing the documentation in the version that you intend to change. The version can be selected from the dropdown in the top menu."
msgid "If you do not have edit rights on the repository (`odoo/documentation-user <https://github.com/odoo/documentation-user>`_), you need to fork it by clicking on the appropriate button. In other terms, you create a copy of the entire repository on your own account. If you do have the edit rights, skip this step."
msgid "Click on the **Preview changes** button to review your contribution in a more human-readable format. Be aware that the preview is not able to handle all markups correctly. Notes and tips, for instance, are not correctly rendered. The version of your content published to the website will be, however."
msgid "Go to the bottom of the page to create a commit (:dfn:`what packs your changes together and labels them with a commit message`) of your changes."
msgid "In first text box, describe your changes. For instance, \"Fix a typo\" and \"Add documentation for invoicing of sales orders\" are two clear commit messages."
msgid "Select the option \"Create a new branch for this commit and start a pull request.\" if you have the choice (if you have partial or full edit writes on the repository). If not, skip this step."
msgid "In the dropdown for the selection of the base branch (i.e., the version of the documentation that your changes concern), make sure to select the same version as in the first step of this guide and click on the **Create pull request** button."
msgid "Double-check your :abbr:`PR (Pull Request)` and, when ready, click again on the **Create pull request** button to submit your changes for review by a redactor at Odoo."
msgid "You're done! If your changes are approved straight away they will appear in the documentation the very next day. It may also be the case that the reviewer has a question or a remark, so make sure to check your notifications or your emails, depending on your account settings."
msgid "We use `Git <https://en.wikipedia.org/wiki/Git>`_ to manage the files of the user documentation. It is a tool that allows to track the history of changes made to a file and, more importantly, to work on different versions of those files at the same time. It means that you do not need to worry about overwriting someone else’s pending work when you start editing the documentation."
msgid "You must then configure Git to identify yourself as the author of your future contribution. Enter the same email address as the one you used to register on GitHub."
msgid "As stated earlier, our documentation (in all its versions) is maintained on GitHub at `github.com/odoo/documentation-user <https://github.com/odoo/documentation-user>`_. A modification is made by the mean of a :abbr:`PR (Pull Request)` (:dfn:`proposal of content changes`) to allow for a review of the changes before updating the sources of the documentation."
msgid "Go to `github.com/odoo/documentation-user <https://github.com/odoo/documentation-user>`_ and click on the **Fork** button in the top right corner."
msgid "If you do not have edit rights on the repository owned by Odoo, replace \"odoo\" with your Github username in the URL of the command above. If you do have edit rights, it is not necessary to fork the repository."
msgid "In order to ease the collaboration between writers coming from many different systems and teams, execute the following group of commands that correspond to your :abbr:`OS (Operating System)` in a terminal."
msgid "Because the documentation is written in :abbr:`RST (reStructuredText)`, it needs to be built (:dfn:`converted to HTML`) in order to display nicely. This is done by the documentation generator which takes the original :abbr:`RST (reStructuredText)` files as input, transforms the markups in a human-readable format, and outputs HTML files to be read in your web browser."
msgid "The documentation generator that we use is called `Sphinx <http://www.sphinx-doc.org/en/master/>`_. and is written in `Python <https://en.wikipedia.org/wiki/Python_(programming_language)>`_. You have to install Python in order to use Sphinx. For the record, Sphinx is the program and Python the programming language, but you do not need to know much more about them so don't panic!"
msgid "Python comes with its own package manager: `pip <https://en.wikipedia.org/wiki/Pip_(package_manager)>`_. It allows installing Python dependencies in a single command."
msgid "`Make <https://en.wikipedia.org/wiki/Make_(software)>`_ is a tool that packs a bunch of command-lines into one to be easier to remember and to type. In our case, it is used to execute complex Sphinx build commands by using a single and simpler one instead."
msgid "`pngquant <https://pngquant.org/>`_ is a tool that we use to compress PNG images so that the documentation does not end up weighting several Gigabytes in a few year span."
msgid "Now that your machine is all set up, it is time to do the same for your version of the documentation files. As it would not be convenient to have several people working on the version 14.0 in parallel (conflicts of content would occur all the time), and in order to be able to create a :abbr:`PR (Pull Request)`, you must `create a new branch <https://www.atlassian.com/git/tutorials/using-branches>`_ starting from the branch 14.0. In other words, you copy the entirety of this version’s files and give it another name. For this example, we will go with ``14.0-my_contribution``."
msgid "You can now perform any change you want to the documentation files. These changes must be compliant with :abbr:`RST (reStructuredText)` syntax (see :doc:`rst_cheat_sheet`) and with our :doc:`guidelines <rst_guidelines>`."
msgid "We expect you to have basic knowledge of Git, which should be enough to cover the basic flow of a one-time contribution. If you plan on submitting several contributions, work on older versions of the documentation or perform any other advanced action, we recommend you to be confident with Git. Help yourself with `this manual of Git <https://www.atlassian.com/git>`_ and `this interactive tutorial <https://learngitbranching.js.org/>`_."
msgid "Go to `github.com/odoo/documentation-user/pulls <https://github.com/odoo/documentation-user/pulls>`_ and click on the **New pull request** button."
msgid "If you forked the base repository in the section :ref:`contributing/fetch-sources`, click on the link **compare across forks** If not, skip this step."
msgid "In the dropdown for the selection of the base branch (i.e., the version of the documentation that your changes concern), make sure to select the version that your changes target (here **14.0**)."
msgid "The symbols used for the formatting are, in fact, not important. Only the order in which they are written matters, as it determines the size of the decorated heading. This means that you may encounter different heading formatting and in a different order, in which case you should follow the formatting in place in the document. In any other case, use the formatting shown below."
msgid "This excerpt of :abbr:`RST (reStructuredText)`: ``For instance, `this is a hyperlink reference <https://odoo.com>`_.`` is rendered as follows in HTML: “For instance, `this is a hyperlink reference <https://odoo.com>`_.”"
msgid "A `proof-of-concept <https://en.wikipedia.org/wiki/Proof_of_concept>`_ is a simplified version, a prototype of what is expected to agree on the main lines of expected changes. `PoC <https://en.wikipedia.org/wiki/Proof_of_concept>`_ is a common abbreviation."
msgid "Internal hyperlink targets follow the same syntax as external hyperlink targets but without any URL. Indeed, they are internal. They allow referencing a specific part of a document by using the target as an anchor. When the user clicks on the reference, the documentation scrolls to the part of the page containing the target."
msgid "Implicit hyperlink targets are a special kind of internal hyperlink targets: they are automatically generated by section titles, footnotes, etc. Consequently, they don’t have a definition syntax."
msgid "This can easily be done by creating a new user, see `How to create a new user? <https://example.com/how-to-create-a-user>`_ for additional help. ..."
msgid "Please refer to `this documentation <https://example.com/doc/accounting/invoices.html>`_ and to `Send a pro-forma invoice <https://example.com/doc/sales/proforma.html>`_."
msgid "The ``download`` directive allows referencing files (that are not necessarily :abbr:`RST (reStructuredText)` documents) within the source tree to be downloaded."
msgid "The ``image`` directive allows inserting images in a document. It comes with a set of optional parameter directives that can individually be omitted if considered redundant."
msgid "The Odoo theme supports banner images at the top of documents. At the first line of your documents, insert the directive ``:banner: banners/file_name.png``. Replace ``file_name.png`` with the file that you placed in :file:`_static/banners` to server as a banner of your document."
msgid "If you made a particular choice of writing or formatting that a future writer should be able to understand and take into account, consider writing a comment. Comments are blocks of text that do not count as a part of the documentation and that are used to pass a message to writers of the source code. They consist of a line starting with two dots and a space, followed by the comment."
msgid "Make use of `this convenient table generator <https://www.tablesgenerator.com/text_tables>`_ to build your tables. Then, copy-paste the generated formatting into your document."
msgid "Markup symbols escaped with backslashes (``\\``) are rendered normally. For instance, ``this \\*\\*line of text\\*\\* with \\*markup\\* symbols`` is rendered as “this \\*\\*line of text\\*\\* with \\*markup\\* symbols”."
msgid "When it comes to backticks (`````), which are used in many case such as :ref:`hyperlink references <contributing/hyperlink-references>`, using backslashes for escaping is no longer an option because the outer backticks interpret enclosed backslashes and thus prevent them from escaping inner backticks. For instance, ```\\`this formatting\\```` produces an ``[UNKNOWN NODE title_reference]`` error. Instead, `````this formatting````` should be used to produce the following result: ```this formatting```."
msgid "If you need to reference an internal documentation page or a file that is not sitting in the same directory as your current page, always make use of *relative file paths* rather than *absolute file paths*. An absolute file path indicates the location of the target from the root of its file tree. A relative file path makes use of smart notations (such as ``../`` git that redirects to the parent folder) to indicate the location of the target *relative* to that of the source document."
msgid "The relative links are clearly superior in terms of readability and stability: the references survive version updates, folder name changes and file tree restructurations."
msgid "In RST, it is possible to break a line without forcing a line break on the rendered HTML. Make use of this feature to write **lines of maximum 100 characters**. A line break in a sentence results in an additional whitespace in HTML. That means that you do not need to leave a trailing whitespace at the end of a line to separate words."
msgid "You can safely break a line around the separators (``-->``) of ``menuselection`` directives and anywhere in a hyperlink reference. For the ``doc``, ``ref`` and ``download`` directives, this is only true for the label part of the reference."
msgid "Use as many spaces at the beginning of an indented line as needed to align it with the first character of the directive in the line above. This usually implies 3 spaces but you only need 2 for bulleted lists."
msgid "Although chaining characters ``‣`` and menu names works fine to indicate a user which menus to click, it is best to use the ``menuselection`` directive (see :ref:`contributing/specialized-directives`) for the same result. Indeed, it renders the menus chain consistently with the rest of the documentation and would automatically adapt to the new graphic chart if we were to switch to a new one. This directive is used inline as follows: ``:menuselection:`Settings --> Products --> Variants```."
msgid "Prefer the use of ``#.`` in numbered lists instead of ``1.``, ``2.``, etc. This removes the risk of breaking the numbering when adding new elements to the list and is easier to maintain."
msgid "Avoid using implicit hyperlink targets and prefer internal hyperlink targets instead. Referencing the implicit target ``How to print quotations?`` is more prone to break than a reference to the explicit target ``_print_quotation`` which never appears in the rendered HTML and is thus even less likely to be modified."
msgid "As hyperlink targets are visible from the entire documentation when referenced with the ``ref`` directive, it is recommended to prefix the target name with that of the related application. For instance, naming a target ``_amazon/form`` instead of ``_form`` avoids unwanted behaviors and makes the purpose of the target clear."
msgid "When refactoring (improving without adding new content) section headings or hyperlink targets, take care not to break any hyperlink reference to these targets or update them accordingly."
msgid "Although using a double-underscore suffix works most of the time for classic hyperlink references, it is not recommended as double-underscores normally indicate an anonymous hyperlink reference. This is a special kind of hyperlink reference that makes use of nameless hyperlink targets consisting only of two underscore."
