mirror of
https://github.com/ManimCommunity/manim.git
synced 2026-06-22 10:01:47 +00:00
* Create crowdin.yml
* try fix yml
* Move files
* Revert "Move files"
This reverts commit 8d53826ae0.
* Update crowdin.yml
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Changed to locale with underscore
* Changing folder for .pot files. And removing the useless sphinx-intl part.
* Updated .gitignore and crowdin configuration to follow the directory change.
* Renaming po to pot EFFECTIVELY
* Changed the file with the new (simpler) generation. Also added better display for `make i18n`
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Change to two letters code
* Correct extension
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Mysaa <samy.avrillon@ens-lyon.fr>
Co-authored-by: Mysaa <mysaa@myssian.home>
83 lines
4.2 KiB
Text
83 lines
4.2 KiB
Text
|
|
msgid ""
|
|
msgstr ""
|
|
"Project-Id-Version: Manim \n"
|
|
"MIME-Version: 1.0\n"
|
|
"Content-Type: text/plain; charset=UTF-8\n"
|
|
"Content-Transfer-Encoding: 8bit\n"
|
|
|
|
#: ../../source/contributing/docstrings.rst:3
|
|
msgid "Adding Docstrings"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:5
|
|
msgid "A docstring is a string literal that is used right after the definition of a module, function, class, or method. They are used to document our code. This page will give you a set of guidelines to write efficient and correct docstrings."
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:11
|
|
msgid "Formatting the Docstrings"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:13
|
|
msgid "Please begin the description of the class/function in the same line as the 3 quotes:"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:31
|
|
msgid "NumPy Format"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:32
|
|
msgid "The Manim Community uses numpy format for the documentation."
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:34
|
|
msgid "Use the numpy format for sections and formatting - see https://numpydoc.readthedocs.io/en/latest/format.html."
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:37
|
|
msgid "This includes:"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:39
|
|
msgid "The usage of ``Attributes`` to specify ALL ATTRIBUTES that a class can have and a brief (or long, if needed) description."
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:43
|
|
msgid "Also, ``__init__`` parameters should be specified as ``Parameters`` **on the class docstring**, *rather than under* ``__init__``. Note that this can be omitted if the parameters and the attributes are the same (i.e., dataclass) - priority should be given to the ``Attributes`` section, in this case, which must **always be present**, unless the class specifies no attributes at all. (See more on Parameters in number 2 of this list.)"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:51
|
|
#: ../../source/contributing/docstrings.rst:151
|
|
msgid "Example:"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:83
|
|
msgid "The usage of ``Parameters`` on functions to specify how every parameter works and what it does. This should be excluded if the function has no parameters. Note that you **should not** specify the default value of the parameter on the type. On the documentation render, this is already specified on the function's signature. If you need to indicate a further consequence of value omission or simply want to specify it on the docs, make sure to **specify it in the parameter's DESCRIPTION**."
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:92
|
|
#: ../../source/contributing/docstrings.rst:128
|
|
msgid "See an example on list item 4."
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:96
|
|
msgid "When documenting varargs (args and kwargs), make sure to document them by listing the possible types of each value specified, like this:"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:109
|
|
msgid "Note that, if the kwargs expect specific values, those can be specified in a section such as ``Other Parameters``:"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:120
|
|
msgid "The usage of ``Returns`` to indicate what is the type of this function's return value and what exactly it returns (i.e., a brief - or long, if needed - description of what this function returns). Can be omitted if the function does not explicitly return (i.e., always returns ``None`` because ``return`` is never specified, and it is very clear why this function does not return at all). In all other cases, it should be specified."
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:130
|
|
msgid "The usage of ``Examples`` in order to specify an example of usage of a function **is highly encouraged** and, in general, should be specified for *every function* unless its usage is **extremely obvious**, which can be debatable. Even if it is, it's always a good idea to add an example in order to give a better orientation to the documentation user. Use the following format for Python code:"
|
|
msgstr ""
|
|
|
|
#: ../../source/contributing/docstrings.rst:144
|
|
msgid "Also, if this is a video- or animation-related change, please try to add an example GIF or video if possible for demonstration purposes."
|
|
msgstr ""
|
|
|
|
|