# SOME DESCRIPTIVE TITLE. # Copyright (C) 2022, The Funkwhale Collective # This file is distributed under the same license as the funkwhale package. # FIRST AUTHOR , 2022. # #, 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 \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" "Generated-By: Babel 2.10.1\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 ""