# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2022, The Funkwhale Collective
# This file is distributed under the same license as the funkwhale package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: funkwhale 1.2.5\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2022-07-01 10:35+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../../documentation/style.rst:2
msgid "Documentation Style Guide"
msgstr ""

#: ../../documentation/style.rst:5
msgid "End-user Documentation"
msgstr ""

#: ../../documentation/style.rst:7
msgid "End-user documentation is often the most difficult to write as it requires striking the right balance between technical and non-technical instruction. Typically, writing a document should start with you asking yourself the following question:"
msgstr ""

#: ../../documentation/style.rst:11
msgid "Why is the user reading this document?"
msgstr ""

#: ../../documentation/style.rst:13
msgid "The answer will usually be one of the following:"
msgstr ""

#: ../../documentation/style.rst:15
msgid "They are new to the project and are looking to learn more about it"
msgstr ""

#: ../../documentation/style.rst:16
msgid "They are trying to do something and are having difficulty"
msgstr ""

#: ../../documentation/style.rst:18
msgid "Documentation should be written with these two answers in mind. Information should be clearly laid out in small sections with plenty of clear examples and precise instructions. You should also try to pre-empt where the user might need to go next in order to ease their journey through the document by providing logical and relevant links to more documents."
msgstr ""

#: ../../documentation/style.rst:24
msgid "Administrator Documentation"
msgstr ""

#: ../../documentation/style.rst:26
msgid "Funkwhale is quite a technical project and is enjoyed by people who like setting up their own systems. These users can range from experienced server administrators to hobbyists, so administrator documentation should include plenty of technical instructions with an easy-to-read explanation of each step to cover both use-cases."
msgstr ""

#: ../../documentation/style.rst:32
msgid "Developer Documentation"
msgstr ""

#: ../../documentation/style.rst:34
msgid "Developer documentation should aim to be as technical and readable as possible. Since the reader is likely a developer themselves, providing as much technical detail as possible is the best course of action as it allows them to dive in to the project's internals with more confidence. It is safe to assume they are used to reading more technical work."
msgstr ""
