1# Licensed to the Apache Software Foundation (ASF) under one 2# or more contributor license agreements. See the NOTICE file 3# distributed with this work for additional information 4# regarding copyright ownership. The ASF licenses this file 5# to you under the Apache License, Version 2.0 (the 6# "License"); you may not use this file except in compliance 7# with the License. You may obtain a copy of the License at 8# 9# http://www.apache.org/licenses/LICENSE-2.0 10# 11# Unless required by applicable law or agreed to in writing, software 12# distributed under the License is distributed on an "AS IS" BASIS, 13# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 14# See the License for the specific language governing permissions and 15# limitations under the License. 16# 17#, fuzzy 18msgid "" 19msgstr "" 20"Project-Id-Version: Apache Traffic Server 6.2\n" 21"Report-Msgid-Bugs-To: \n" 22"POT-Creation-Date: 2016-01-02 21:32+0000\n" 23"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" 24"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" 25"Language-Team: LANGUAGE <LL@li.org>\n" 26"MIME-Version: 1.0\n" 27"Content-Type: text/plain; charset=utf-8\n" 28"Content-Transfer-Encoding: 8bit\n" 29"Generated-By: Babel 2.1.1\n" 30 31#: ../../developer-guide/documentation/conventions.en.rst:23 32msgid "Conventions" 33msgstr "" 34 35#: ../../developer-guide/documentation/conventions.en.rst:25 36msgid "" 37"The conventions detailed in this chapter should be followed when modifying " 38"the project documentation to maintain readability and consistency." 39msgstr "" 40 41#: ../../developer-guide/documentation/conventions.en.rst:29 42msgid "Typographic" 43msgstr "" 44 45#: ../../developer-guide/documentation/conventions.en.rst:43 46msgid "Italic" 47msgstr "" 48 49#: ../../developer-guide/documentation/conventions.en.rst:32 50msgid "" 51"Used to introduce new terms. Italics used solely for emphasis should be " 52"avoided. When introducing new terms, only the first use should be set in " 53"italics, and its introduction should be followed with a definition or " 54"description of the term." 55msgstr "" 56 57#: ../../developer-guide/documentation/conventions.en.rst:37 58#: ../../developer-guide/documentation/conventions.en.rst:55 59#: ../../developer-guide/documentation/conventions.en.rst:64 60msgid "Example::" 61msgstr "" 62 63#: ../../developer-guide/documentation/conventions.en.rst:47 64msgid "Bold" 65msgstr "" 66 67#: ../../developer-guide/documentation/conventions.en.rst:46 68msgid "" 69"Bold typesetting is to be reserved for section, table, and glossary " 70"headings and should be avoided in paragraph copy." 71msgstr "" 72 73#: ../../developer-guide/documentation/conventions.en.rst:58 74msgid "Monospace" 75msgstr "" 76 77#: ../../developer-guide/documentation/conventions.en.rst:50 78msgid "" 79"Used to indicate filesystem paths, variable names, language keywords and " 80"functions, and command output. Note that in the case of variables and " 81"functions, whenever possible references to their documentation should be " 82"used in place of simple monospace markup." 83msgstr "" 84 85#: ../../developer-guide/documentation/conventions.en.rst:68 86msgid "Bracketed Monospace" 87msgstr "" 88 89#: ../../developer-guide/documentation/conventions.en.rst:61 90msgid "" 91"Used to indicate, within command or source code examples, variables for " 92"which the reader should substitute a value." 93msgstr "" 94 95#: ../../developer-guide/documentation/conventions.en.rst:72 96msgid "Ellipsis" 97msgstr "" 98 99#: ../../developer-guide/documentation/conventions.en.rst:71 100msgid "" 101"Used to indicate the omission of irrelevant or unimportant information. May " 102"also be used to separate matter to be treated in detail elsewhere." 103msgstr "" 104 105#: ../../developer-guide/documentation/conventions.en.rst:75 106msgid "Layout Styles" 107msgstr "" 108 109#: ../../developer-guide/documentation/conventions.en.rst:78 110msgid "Block Content" 111msgstr "" 112 113#: ../../developer-guide/documentation/conventions.en.rst:85 114msgid "Notes" 115msgstr "" 116 117#: ../../developer-guide/documentation/conventions.en.rst:81 118msgid "" 119"Use of ``.. note::`` blocks should be sparing. In most rendered forms, the " 120"note block will appear quite prominently and draw the readers' eyes away " 121"from the surrounding copy. It is therefore advisable that the note itself " 122"provide enough context and detail to be read on its own, without a full " 123"reading of the surrounding copy." 124msgstr "" 125 126#: ../../developer-guide/documentation/conventions.en.rst:96 127msgid "Important Notes" 128msgstr "" 129 130#: ../../developer-guide/documentation/conventions.en.rst:88 131msgid "" 132"The use of ``.. important::`` callout blocks should be limited only to " 133"those situations in which critical information needs to be prominently " 134"displayed. Suitable use would include noting that resizing a cache voiume " 135"will result in |TS| resetting the cache contents to empty when the service " 136"is started. This is information that may not be obvious, or safe to assume, " 137"for the reader but which can significantly (and negatively) impact the use " 138"and performance of |TS| in their environment. Important note blocks should " 139"not be used for behavior or actions which generally do not have potential " 140"negative side effects." 141msgstr "" 142 143#: ../../developer-guide/documentation/conventions.en.rst:100 144msgid "Sidebars" 145msgstr "" 146 147#: ../../developer-guide/documentation/conventions.en.rst:99 148msgid "" 149"The use of ``.. sidebar::`` blocks in |TS| documentation should be avoided, " 150"and note blocks favored in their place." 151msgstr "" 152 153#: ../../developer-guide/documentation/conventions.en.rst:108 154msgid "Code Samples" 155msgstr "" 156 157#: ../../developer-guide/documentation/conventions.en.rst:103 158msgid "" 159"Content should be set within ``.. code::`` blocks whenever a full line or " 160"multiple lines of source code are being included in the documentation, or " 161"when example shell or network commands are being demonstrated. Blank lines " 162"may be used to separate lines of code within the block for readability, and " 163"all normal indentation practices should be followed. No additional markup " 164"should be used within the content block." 165msgstr "" 166 167#: ../../developer-guide/documentation/conventions.en.rst:114 168msgid "Definition Lists" 169msgstr "" 170 171#: ../../developer-guide/documentation/conventions.en.rst:111 172msgid "" 173"Definition lists may be used in multiple ways, not just for the term " 174"listings in the glossary section. They may be used to provide individual " 175"detailed treatment for a list of function or command arguments or where any " 176"series of terms need to be explained outside of the formal glossary." 177msgstr "" 178 179#: ../../developer-guide/documentation/conventions.en.rst:120 180msgid "Ordered Lists" 181msgstr "" 182 183#: ../../developer-guide/documentation/conventions.en.rst:117 184msgid "" 185"Explicityly numbered ordered lists should be avoided. |RST| provides two " 186"methods of marking up ordered, numbered lists, and the automatic numbering " 187"form should be used in all cases where surrounding paragraphs do not need " 188"to reference individual list entries." 189msgstr "" 190 191#: ../../developer-guide/documentation/conventions.en.rst:123 192msgid "Tables" 193msgstr "" 194 195#: ../../developer-guide/documentation/conventions.en.rst:125 196msgid "" 197"Tabular content may be used in any situation where a selection of items, " 198"terms, options, formats, etc. are being compared or where a grouping of the " 199"same are being presented alongside a small number of attributes which do " 200"not require detailed expositions." 201msgstr "" 202 203#: ../../developer-guide/documentation/conventions.en.rst:130 204msgid "" 205"The |TS| project documentation supplies a custom styling override which " 206"causes cell contents to wrap within wide tables whenever possible in cases " 207"where it is necessary to prevent the content from overflowing into the " 208"margin. If, however, the cell content cannot be wrapped because there are " 209"no breaking spaces present (for example, a long variable name containing " 210"only letters, periods, underscores, dashes, and so no, but no whitespace), " 211"the table may still require overflowing into the page margin. Whenever " 212"possible, please try to avoid the use of tables when presenting information " 213"that will lead to this, as it greatly hampers readability on smaller " 214"screens, especially tablets and mobile devices. Alternatives such as a " 215"definition list may be better suited to the content." 216msgstr "" 217 218#: ../../developer-guide/documentation/conventions.en.rst:141 219msgid "" 220"Tables may be marked up using any of the |RST| styles, though it is " 221"generally easiest to maintain those using the *simple* table markup style." 222msgstr "" 223 224#: ../../developer-guide/documentation/conventions.en.rst:145 225msgid "Structural" 226msgstr "" 227 228#: ../../developer-guide/documentation/conventions.en.rst:148 229msgid "Common Definitions" 230msgstr "" 231 232#: ../../developer-guide/documentation/conventions.en.rst:150 233msgid "" 234"The |TS| project documentation maintains a common definitions, " 235"abbreviations, and shortcut listing in the file ``doc/common.defs``. This " 236"file should be included by all |RST| source files after the standard " 237"project copyright notice." 238msgstr "" 239 240#: ../../developer-guide/documentation/conventions.en.rst:154 241msgid "" 242"The file should always be included using a relative path from the current " 243"file's location. Any commonly or repeatedly used abbreviations, especially " 244"those of product, company, or person names, should be added to the " 245"definitions file as useful to avoid repetitive typing and ensure accurate " 246"spellings or legal usage." 247msgstr "" 248 249#: ../../developer-guide/documentation/conventions.en.rst:160 250msgid "Tables of Content" 251msgstr "" 252 253#: ../../developer-guide/documentation/conventions.en.rst:162 254msgid "" 255"Any chapters of non-trivial scope should begin with a table of contents on " 256"the chapter index. The ``:depth:`` option for the table of contents may be " 257"set to a value appropriate to the amount of content in the chapter " 258"sections. A depth of ``2`` will generally provide a balance between " 259"usefully describing the contents of the chapter without overwhelming a " 260"reader scanning for topics relevant to their needs or interests." 261msgstr "" 262 263#: ../../developer-guide/documentation/conventions.en.rst:170 264msgid "Sections and Headings" 265msgstr "" 266 267#: ../../developer-guide/documentation/conventions.en.rst:172 268msgid "" 269"Each chapter section should be located in a separate |RST| file. Each file " 270"should contain the standard project copyright notice first, followed by a " 271"unique reference marker for the section." 272msgstr "" 273 274#: ../../developer-guide/documentation/conventions.en.rst:176 275msgid "" 276"While |RST| itself does not define a fixed ordering of section markers, |" 277"TS| documentation source files should use the same set of single line " 278"section markings, proceeding through the section levels without skipping. " 279"For consistency, the following section line markers should be used in " 280"order::" 281msgstr "" 282 283#: ../../developer-guide/documentation/conventions.en.rst:193 284msgid "" 285"Any section file which reaches or has need to exceed the fourth level style " 286"of section line markings is an excellent candidate for breaking into " 287"several smaller, and ideally more focused, |RST| source files and " 288"referenced by an index with its own table of contents." 289msgstr "" 290 291#: ../../developer-guide/documentation/conventions.en.rst:199 292msgid "Footnotes and Endnotes" 293msgstr "" 294 295#: ../../developer-guide/documentation/conventions.en.rst:201 296msgid "" 297"Both footnotes and endnotes should be avoided. The |TS| documentation is " 298"intended primarily for online viewing and the positioning of footnotes in " 299"the rendered output is not always intuitive. In cases where a footnote " 300"might have been appropriate in print-oriented material for referencing an " 301"external resource, that reference is more ideally integrated as a standard |" 302"RST| reference." 303msgstr "" 304 305#: ../../developer-guide/documentation/conventions.en.rst:208 306msgid "" 307"For more descriptive content that might have been included as a footnote, " 308"it is less disruptive and more useful to choose between reformullating the " 309"text to simply include the additional wording, or consider the use of an " 310"inline note block." 311msgstr "" 312 313#: ../../developer-guide/documentation/conventions.en.rst:214 314msgid "Grammatical" 315msgstr "" 316