The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: listitem/screen
Context English State
Personal attacks are discouraged. As good net-citizens, we should try to hold ourselves to high standards of behavior.
Spam is not allowed, ever. The mailing lists are actively processed to ban offenders to this rule.
What is considered proper etiquette when posting to the mailing lists?
Please wrap lines at 75 characters, since not everyone uses fancy GUI mail reading programs.
Please respect the fact that bandwidth is not infinite. Not everyone reads email through high-speed connections, so if your posting involves something like the content of <filename>config.log</filename> or an extensive stack trace, please consider putting that information up on a website somewhere and just provide a URL to it. Remember, too, that these postings will be archived indefinitely, so huge postings will simply inflate the size of the archives long after their purpose has expired.
Format your message so that it is legible, and PLEASE DO NOT SHOUT!!!!!. Do not underestimate the effect that a poorly formatted mail message has, and not just on the FreeBSD mailing lists. Your mail message is all that people see of you, and if it is poorly formatted, badly spelled, full of errors, and/or has lots of exclamation points, it will give people a poor impression of you.
Please use an appropriate human language for a particular mailing list. Many non-English mailing lists are <link xlink:href="@@URL_RELPREFIX@@/community/mailinglists.html"> available</link>.
For the ones that are not, we do appreciate that many people do not speak English as their first language, and we try to make allowances for that. It is considered particularly poor form to criticize non-native speakers for spelling or grammatical errors. FreeBSD has an excellent track record in this regard; please, help us to uphold that tradition.
Please use a standards-compliant Mail User Agent (MUA). A lot of badly formatted messages come from <link xlink:href="">bad mailers or badly configured mailers</link>. The following mailers are known to send out badly formatted messages without you finding out about them:
<trademark class="registered">Microsoft</trademark> Exchange
<trademark class="registered">Microsoft</trademark> <trademark class="registered">Outlook</trademark>
Try not to use <acronym>MIME</acronym>: a lot of people use mailers which do not get on very well with <acronym>MIME</acronym>.
Make sure your time and time zone are set correctly. This may seem a little silly, since your message still gets there, but many of the people on these mailing lists get several hundred messages a day. They frequently sort the incoming messages by subject and by date, and if your message does not come before the first answer, they may assume that they missed it and not bother to look.
A lot of the information you need to supply is the output of programs, such as <citerefentry><refentrytitle>dmesg</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or console messages, which usually appear in <filename>/var/log/messages</filename>. Do not try to copy this information by typing it in again; not only it is a real pain, but you are bound to make a mistake. To send log file contents, either make a copy of the file and use an editor to trim the information to what is relevant, or cut and paste into your message. For the output of programs like <command>dmesg</command>, redirect the output to a file and include that. For example,
<prompt>%</prompt> <userinput>dmesg &gt; /tmp/dmesg.out</userinput>
This redirects the information to the file <filename>/tmp/dmesg.out</filename>.
When using cut-and-paste, please be aware that some such operations badly mangle their messages. This is of particular concern when posting contents of <filename>Makefiles</filename>, where <literal>tab</literal> is a significant character. This is a very common, and very annoying, problem with submissions to the <link xlink:href="@@URL_RELPREFIX@@/support.html"> Problem Reports database</link>. <filename>Makefiles</filename> with tabs changed to either spaces, or the annoying <literal>=3B</literal> escape sequence, create a great deal of aggravation for committers.
What are the special etiquette consideration when replying to an existing posting on the mailing lists?
Please include relevant text from the original message. Trim it to the minimum, but do not overdo it. It should still be possible for somebody who did not read the original message to understand what you are talking about.
This is especially important for postings of the type "yes, I see this too", where the initial posting was dozens or hundreds of lines.
Use some technique to identify which text came from the original message, and which text you add. A common convention is to prepend <quote><literal>&gt; </literal></quote> to the original message. Leaving white space after the <quote><literal>&gt; </literal></quote> and leaving empty lines between your text and the original text both make the result more readable.
Please ensure that the attributions of the text you are quoting is correct. People can become offended if you attribute words to them that they themselves did not write.
Please do not <literal>top post</literal>. By this, we mean that if you are replying to a message, please put your replies after the text that you copy in your reply.
A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?
(Thanks to Randy Bush for the joke.)
Recurring Topics On The Mailing Lists
Participation in the mailing lists, like participation in any community, requires a common basis for communication. Many of the mailing lists presuppose a knowledge of the Project's history. In particular, there are certain topics that seem to regularly occur to newcomers to the community. It is the responsibility of each poster to ensure that their postings do not fall into one of these categories. By doing so, you will help the mailing lists to stay on-topic, and probably save yourself being flamed in the process.
The best method to avoid this is to familiarize yourself with the <link xlink:href=""> mailing list archives</link>, to help yourself understand the background of what has gone before. In this, the <link xlink:href=""> mailing list search interface</link> is invaluable. (If that method does not yield useful results, please supplement it with a search with your favorite major search engine).
By familiarizing yourself with the archives, not only will you learn what topics have been discussed before, but also how discussion tends to proceed on that list, who the participants are, and who the target audience is. These are always good things to know before you post to any mailing list, not just a FreeBSD mailing list.
Component Translation Difference to current string
This translation Translated FreeBSD Doc (Archived)/articles_mailing-list-faq
The following string has the same context and source.
Translated FreeBSD Doc (Archived)/articles_freebsd-questions


No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

Following checks are failing:
Unchanged translation: Spanish, Portuguese (Brazil)


Source information

Source string comment
(itstool) path: listitem/screen
no-wrap, read-only
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/mailing-list-faq.pot, string 49