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