http://kb.mozillazine.org/api.php?action=feedcontributions&user=Wintogreen&feedformat=atomMozillaZine Knowledge Base - User contributions [en]2024-03-28T14:59:24ZUser contributionsMediaWiki 1.40.1http://kb.mozillazine.org/index.php?title=Mozilla_Suite_:_FAQs_:_Status&diff=22651Mozilla Suite : FAQs : Status2006-02-03T05:12:11Z<p>Wintogreen: /* Mozilla Suite code development and the SeaMonkey project */</p>
<hr />
<div>== Mozilla Suite code development and the SeaMonkey project ==<br />
<br />
The 1.7 release of the Mozilla Suite is the last major release as an official Mozilla Foundation product. It will be maintained with 1.7.x version releases to fix known security problems or other critical issues but there will be no official Mozilla Suite 1.8 release. This will enable the Foundation to devote its resources to the standalone Firefox and Thunderbird applications.<br />
<br />
Although official development has ceased, the Suite will continue to evolve as a community-led ''project'' and will receive substantial support from the Foundation. In particular, the development community will still use mozilla.org's webtools such as CVS, LXR and [[Bugzilla]], and Foundation members have provided significant advice to the community on how to organise successful releases of a Gecko-based application suite. The project will be "driven" by members of the community who will be responsible for maintaining code, dictating the release schedule and performing QA on the final releases. More information on the organisational structure that has developed to maintain the suite and manage future releases is on the [http://wiki.mozilla.org/SeaMonkey:Home_Page SeaMonkey homepage] of the [http://wiki.mozilla.org/ mozilla.org wiki]. <br />
<br />
Since this community-led project does not result in an official Mozilla Foundation product, it was agreed that the name and version number of the new release must change, as it is not possible to use the "Mozilla" trademark on an unofficial product. The name "SeaMonkey" was chosen, after the longtime codename of the Mozilla Suite. This new release of the application suite, based on Mozilla Suite 1.8 code, is named "SeaMonkey 1.0" and was released on January 30, 2006.<br />
<br />
== Differences between the Mozilla Suite and SeaMonkey ==<br />
<br />
Despite the name change, SeaMonkey 1.0 will feel very familiar to Mozilla Suite users, but it will incorporate numerous new features, UI improvements, and bugfixes. Some of these will be listed in the release notes, available through the [http://www.mozilla.org/projects/seamonkey/ SeaMonkey project page].<br />
<br />
<br />
''This section is a [[stub articles|stub]]. You can help MozillaZine Knowledge Base by expanding it.''<br />
<br />
=="Mozilla Suite" vs. "SeaMonkey" in Knowledge Base articles==<br />
<br />
Contributors to this Knowledge Base are in the process of [[Knowledge Base changes|trying to formulate a scheme]] for how best to refer to the Mozilla Suite and SeaMonkey in Knowledge Base articles and categorize the articles related to each. Until that scheme is worked out and eventually implemented, you may find one or both names used in different articles. For the time being, it is generally safe to assume that all references to "Mozilla Suite" also apply to "SeaMonkey".<br />
<br />
In some articles, especially those written for Thunderbird, there may be a note stating that the article "also applies to Mozilla Suite / SeaMonkey". This could mean that the article applies to both products (most likely) or perhaps only to SeaMonkey (e.g., due to new features in SeaMonkey that are lacking in the Mozilla Suite). Article writers often don't know the specific differences between Mozilla Suite and SeaMonkey and thus use the shorthand "Mozilla Suite / SeaMonkey" note to flag articles that might be of interest to Mozilla Suite and/or SeaMonkey users.<br />
<br />
==See also==<br />
* [[Summary of Mozilla products]]<br />
* [[Mozilla Suite]] articles in this Knowledge Base.<br />
<br />
==External links==<br />
* [http://www.mozilla.org/seamonkey-transition.html Transition plan] on the decision to not release a version 1.8 of the Mozilla Suite<br />
* [http://wiki.mozilla.org/SeaMonkey:Home_Page SeaMonkey homepage] in the mozilla.org wiki<br />
* [http://weblogs.mozillazine.org/seamonkey/ SeaMonkey weblog] with updates on development progress<br />
* [http://www.mozilla.org/projects/seamonkey/ SeaMonkey product page] where you can download SeaMonkey and access the release notes<br />
* [http://www.mozilla.org/products/mozilla1.x/ Mozilla Suite product page] where you can download the latest 1.7.x version of Mozilla Suite<br />
<br />
[[Category:Mozilla Suite]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:In-house_style&diff=22650Talk:In-house style2006-02-03T05:09:46Z<p>Wintogreen: /* Proposed style guideline */</p>
<hr />
<div>==Archive of resolved issues==<br />
Some of the issues discussed here seem to have been resolved for all intents and purposes, so I'm moving them to [[Talk:In-House Style/Resolved]] to clear away the clutter. --[[User:Wintogreen|Wintogreen]] 00:35, 27 Mar 2005 (PST)<br />
In particular:<br />
* Rules; article titles<br />
* Articles that apply to two or more products<br />
* Capitalization of common terms<br />
<br />
If you want to re-open one of these discussions, please do it here on this page, not on the archive page.<br />
<br />
==Application names==<br />
How do we refer to the browser included within the Mozilla Suite? Is it itself called Mozilla Suite, or do we refer to it as the "Mozilla Suite browser" or the "browser in the Mozilla Suite" or something else? Surely many articles for the Mozilla Suite pertain solely to the browser component and not to the whole suite. --[[User:Mozcerize|Mozcerize]] 05:54, 10 Apr 2005 (PDT)<br />
:I thought we'd just call it Mozilla Suite, when it's clear info only applies to the browser.--[[User:Asqueella|asqueella]]<br />
::But sometimes it's not clear: see [[increasing startup speed]] where It is not obvious which app we are talking about if we don't specify that it's the browser. --[[User:Mozcerize|Mozcerize]]<br />
<br />
I think we talked about this before, briefly, but are we sure we're going to stick with "Mozilla Suite" now that the "SeaMonkey" project has an official name? Already I see "Seamonkey" being used in one new page ([[Standard diagnostic]]). If we decide to go with SeaMonkey, it's going to be a major pain to change everything. Again. --[[User:Wintogreen|Wintogreen]] 05:51, 6 Jul 2005 (PDT)<br />
<br />
==-> vs. |==<br />
<br />
I&rsquo;m just hoping to initiate some discussion as to the relative merits of &ldquo;->&rdquo; and &ldquo;|&rdquo; for denoting menu sequences:<br />
<br />
"Tools -> Options -> Privacy -> Cookies"<br />
<br />
"Tools | Options | Privacy | Cookies"<br />
<br />
I&rsquo;ve seen both used all over the place. Also, there seems to be little concensus on what to do about tabs (eg Privacy in the the example above is the equivalent of a tab in an options dialog) and subsections (eg Cookies in the example above). Are these to be treated in the same way (ie using -> or |)? It would be useful to turn to some of the computing textbooks out there and copy what they do. Does anyone have any comments on this? --[[User:Mozcerize|Mozcerize]]<br />
<br />
:Whichever one is chosen should apply to both tabs and menus, I suppose, for consistency matters; you could add a "(tab)" parenthetical remark next to the tab to clarify matters (e.g. "Menu -> Menu -> Dialog -> General (tab)"). --hao2lian<br />
<br />
::What about the HTML entity &amp;rarr; (&rarr;)? For what it's worth, I've seen textbooks that use the pipe but never the discrete characters dash and greater-than. --[[User:Unarmed|Unarmed]] 07:02, 23 Feb 2005 (PST)<br />
<br />
:Well, &rarr; is certainly a lot nicer than ->, but the trouble is that it&rsquo;s always difficult to get people to use HTML entities, particularly when the symbol is going to be typeset frequently. The advantage of &ldquo;|&rdquo; is that it&rsquo;s very easy to type! --[[User:Mozcerize|Mozcerize]]<br />
<br />
::I vote for using "->" and if possible, install a Mediawiki hack that will replace that with a pretty arrow. We should also note on this page whether it is recommended to put spaces before and after the arrow. --asqueella<br />
<br />
:Well, if tha Mediawiki hack is possible then I vote for that too. It seems like the best compromise. --[[User:Mozcerize|Mozcerize]]<br />
<br />
==Hyphen vs. dash==<br />
PS, I totally agree with differentiating hyphens and dashes. (A pet peeve for me, too!) Now if only I can convince everyone to use single and double quotation marks (&amp;lsquo; [&lsquo;], &amp;rsquo; [&rsquo;], &amp;ldquo; [&ldquo;], &amp;rdquo; [&rdquo;]) instead of single and double neutral quotes (', " achieved using your ASCII keyboard) in every situation except marking up computer code&hellip;. Even better, will I manage to get people to use a single right quotation mark (&amp;rsquo; [&rsquo;]) instead of a single neutral quote (') or the equivalent (and hence completely misnamed) entity &amp;apos; when typing an apostrophe? :-P<br />
<br />
:kerz could be petitioned to install a Mediawiki hack to do this, since I'm sure there's one out there. --hao2lian<br />
<br />
OK, so these characters don&rsquo;t look too &ldquo;curly&rdquo; in the default font and size on Firefox, but they certainly do when you increase the text size in a couple of times&mdash;try it! Also, the difference is very obvious in smaller font sizes in serif fonts, and in the default font and size in IE. All of these suggestions are advocated by Unicode [http://www.unicode.org/versions/Unicode4.0.0/] (View the PDF for Chapter&nbsp;6, Section&nbsp;6.2, General Punctuation.) Note that the use of the entity name &lsquo;apos&rsquo; was a horrendous blunder made in the days before decent computer fonts were mainstream.<br />
--[[User:Mozcerize|Mozcerize]] 04:01, 10 Feb 2005 (PST)<br />
<br />
<br />
==Whitespace around dashes==<br />
Personally I prefer using whitespace around emdashes, especially since Gecko still doesn't properly allow linebreaks after that character.<br />
<br />
:Personally, I prefer a tiny bit of whitespace around emdashes too. However, the amount varies from publisher to publisher, and it is correctly achieved not by surrounding the emdash with inter-word spaces but simply by typesetting the emdash with some surrounding space "built in" to the character. So it's really a Gecko issue rather than a user issue. I wasn't aware that Gecko refuses to break lines after emdashes. The spacing issue is an irritant but not a bug; the line-break issue is a bug. I shall go and investigate it! --[[User:Mozcerize|Mozcerize]] 01:06, 22 Feb 2005 (PST)<br />
<br />
::I believe the issue is covered by either [https://bugzilla.mozilla.org/show_bug.cgi?id=95067 Bug 95067: line-break should be allowed after hyphens (unless followed by a number)] or [https://bugzilla.mozilla.org/show_bug.cgi?id=255990 Bug 255990: Characters below U+0100 are not subject to line breaking rules at all] --[[User:Unarmed|Unarmed]] 20:39, 26 Feb 2005 (PST)<br />
<br />
<br />
==Active voice==<br />
Unarmed, I think you mean "use the imperative" rather than "use the active voice". "Help old ladies", "helping old ladies" and "helped old ladies" are all in the active voice. --[[User:Mozcerize|Mozcerize]] 03:17, 23 Feb 2005 (PST)<br />
<br />
:Yes. I knew what I meant, but I had the incorrect term -- I just knew that it wasn't "infinitive." :) --[[User:Unarmed|Unarmed]] 06:53, 23 Feb 2005 (PST)<br />
<br />
::Ok, changed. :) --[[User:Mozcerize|Mozcerize]]<br />
<br />
Is it really a good idea? To my eye, [[Uninstalling extensions]] is better than ''Uninstall extensions'' and [[Using keyword searches]] is better than ''Use keyword searches''. The former implies there's a walk-through or a tutorial on the topic, the latter looks like you advise user to uninstall all of his extensions.<br />
--[[User:Asqueella|asqueella]]<br />
<br />
:Well, I largely agree with you asqueella. In general these things look better when the present participle is used, as in "uninstalling extensions". (The original proposal to use the imperative form was not mine. I believe Wikipedia advocate the use of the present participle too.) I would say that all in-page headings should be in this format. <br />
<br />
:For topic titles, one advantage of using the imperative is when it comes to linking one page to another. In many articles in the KB, you want to be able to say things like "If you are having trouble finding what you want, you should ''use keyword searches''" and you would be able to provide the link to "use keyword searches" simply by typing [ [use keyword searches] ]. However, you gain nothing when the first letter of the topic title is capitalized, since you would normally have to reword the link to remove the capitalization anyway.<br />
<br />
:Hence, I advocate either abandoning initial capitalization and using the imperative, or keeping initial capitalization and using the present participle.<br />
:--[[User:Mozcerize|Mozcerize]] 02:16, 26 Feb 2005 (PST)<br />
<br />
:: ''"For topic titles, one advantage of using the imperative is when it comes to linking one page to another."''<br />
:: But then you can't use accidental linking when using the participle, e.g. "[[Uninstalling extensions]] is very easy" :)<br />
:: I think that we should use present participle when appropriate '''and''' decapitalize first letters of words. --[[User:Asqueella|asqueella]]<br />
<br />
: ''"But then you can't use accidental linking when using the participle, e.g. "[[Uninstalling extensions]] is very easy" :)"''<br />
: lol, indeed :-)<br />
:I agree with your suggestion. --[[User:Mozcerize|Mozcerize]]<br />
<br />
Hmm. I say it depends on the article. To my ear, "Using Templates" sounds better than "Use Templates" but "Resend Message" sounds better than "Resending Message". So, let the page authors use their own judgment. And by the way, "infinitive" is the correct term; it's just that imperatives use the infinitive form. --wintogreen<br />
<br />
:Well, "Resend Message" sounds like it's a phrase taken from a dialog or button or something, so it should be kept unchanged. I think that outside of that context, "resending a message" sounds better that "Resend message". At the moment the KB is a mix of both, even on the same page, which is far from ideal.<br />
<br />
:BTW, "imperative" is the correct term. An infinitive in English consists (usually) of the word "to" followed by a verb form (sometimes called a ''bare infinitive''). The imperative is simply the bare infinitive (ie the infinitive with "to" removed).<br />
<br />
:--[[User:Mozcerize|Mozcerize]] 08:31, 27 Feb 2005 (PST)<br />
<br />
'''Update''': I went ahead and deleted the line about using the imperative, due to the lack of consensus here. Unless we can come up with an easily agreed upon, simply expressed guideline, I don't think there's any point in including it in the Style guide. --[[User:Wintogreen|Wintogreen]] 01:08, 27 Mar 2005 (PST)<br />
<br />
==Keyboard shortcuts==<br />
Should keyboard shortcuts like Ctrl+D be in quotes or italicized or bold? --[[User:Asqueella|asqueella]]<br />
<br />
:Ideally, someone should allow the <code>kbd</code> HTML element and we can worry about it in CSS. And while the subject is up, I propose we enclose modifier keys and function keys in brackets: [Ctrl]+D, [F7], [Shift]+[Del] --[[User:Unarmed|Unarmed]] 17:01, 26 Feb 2005 (PST)<br />
<br />
:: fwiw, I'm not fond of enclosing keys in square brackets. And it's not widely used currently. Not sure that <kbd> element is a good idea - just think about all the times you'll have to type: <kbd></kbd>... --[[User:Asqueella|asqueella]] 17:14, 26 Feb 2005 (PST)<br />
<br />
::: I could concede the brackets, but I really do feel that <code>kbd</code> is the most appropriate option here. It's also used in the internal Firefox help file. --[[User:Unarmed|Unarmed]] 20:22, 26 Feb 2005 (PST)<br />
<br />
:: I think <code>kbd</code> is appropriate, but it's going to be quite hard to enforce. Many people ''really'' don't like typing much ;-). Is there any way of using an easier ASCII structure (eg ^) to indicate keyboard input, and then get the Wiki to do its funky stuff to convert it? --[[User:Mozcerize|Mozcerize]]<br />
<br />
:::I vote for quotes, as currently in the current In-House Style page. It's easy to type, easy enough to read, and consistent with using quotes for menu hierarchy. Italics and bold should be used for emphasis, not for describing mouse movements or keystrokes. IMHO, of course. I would change my vote to <kbd> if a formatting button could be added for it; it'd be too tedious to have to type it out all the time. --wintogreen<br />
<br />
==URLs==<br />
Please don't use the syntax <nowiki>[[wikipedia:articlename]]</nowiki> to link to an article on Wikipedia, since this prevents the link from being recognized as external to the KB and hence it is not displayed with the "[http:// &nbsp;]" symbol. This is confusing for users, since ordinarily only internal links are displayed without this symbol. (The syntax exists to make Wikipedia authors' lives easier, and is available in the KB purely because this Wiki is based on the one they use.) Instead, link to Wikipedia using <nowiki>[http://www.wikipedia.org/wiki/articlename]</nowiki>.<br />
<br />
:This could be changed by removing (or changing) the <code>#bodyContent a.extiw, #bodyContent a.extiw:active</code> rule from line 538 of <code>/stylesheets/monobook/main.css</code>. --[[User:Unarmed|Unarmed]] 13:37, 8 Mar 2005 (PST)<br />
<br />
::Indeed, I've [[User talk:Hao2lian | requested]] that some such change be made to the stylesheet. --[[User:Mozcerize|Mozcerize]] 01:52, 9 Mar 2005 (PST)<br />
<br />
==plugin or plug-in==<br />
I like plugin more, and I also think it's more correct (talking about noun).<br />
Anyone has opinions on this?<br />
: hao2lian has gone ahead and replaced plug-in -> plugin on the page I was thinking about ([[Windows Media Player]]). Adding this variant to the main page, if you think this is incorrect, comment here.<br />
[[User:Asqueella|asqueella]]<br />
<br />
==moved pages with Kb: prefix back==<br />
They don't make sense. Either use a namespace or don't prefix them at all. The person who made those changes hasn't contributed recently (and only made those changes). [[User:Asqueella|asqueella]] 03:29, 29 Mar 2005 (PST)<br />
<br />
==Path, folder and file names==<br />
I think it was decided to use <nowiki><tt></nowiki> tags for these, but does that mean quote marks around the folder/file name should no longer be used (as was the original suggestion)? Here's a [[Thunderbird : FAQs : Changing Mail Storage Location|test case]] where I used <nowiki><tt></nowiki> for folder names without quotes. Doesn't look great to me. Ideas? --wintogreen<br />
:Hm, I must have missed something, but I don't remember the suggestion to use quotes around file names and paths. I remember that suggestion for keyboard shortcuts only.<br />
:About file paths, I brought this up, suggesting the use of &lt;tt&gt;, Unarmed replied saying his only requirement is using fixed-width, and nobody else commented for quite a while. To my eye, &lt;tt&gt; looks okay. Not perfect, but okay. Do you like quotes + variable width, like "profile"? [[User:Asqueella|asqueella]]<br />
::I wouldn't like to see quotes + variable width; we're already using that for several different things. I too think that fixed width is important. I also agree that it doesn't look perfect, but it's okay.<br />
::Can't remember if I've said this before, but I think folders whose location varies should be written as <tt>&lt;profile folder&gt;</tt> and <tt>&lt;install folder&gt;</tt> so that subfolders would be written as <tt>&lt;profile folder&gt;/chrome</tt> etc. If the author wishes he can link to the [[Profile folder]] article, eg <tt>&lt;[[Profile folder | profile folder]]&gt;/chrome</tt>. --[[User:Mozcerize|Mozcerize]] 15:02, 29 Mar 2005 (PST)<br />
:::Thanks for the feedback. Asquella, the original idea was to use quote marks around just file names (not folder names also; my mistake). You'll see it if you go back in the page history. Quote marks with <nowiki><tt></nowiki> actually looks OK, but I think it's formatting overkill. (I'm going to resume my comments below. No indent...) --wintogreen<br />
::::Just a quick note, I thought Mozcerize meant to use "<profile folder>" when it's part of a path only. I.e. "Find your [[profile folder]]", but "<profile folder>/chrome/chrome.rdf", so example (3) doesn't make sense.<br />
::::So I think actually what you mean is to enclose ''paths'', e.g. <tt>C:\Program Files\Mozilla Firefox</tt> or <tt><profile folder>\extensions</tt> in &lt;tt&gt; tags, but name of files/directories, like "chrome" or "cookies.txt" in parentheses. That's fine with me. &lt;tt&gt; inside quotes looks bad to me. --[[User:Asqueella|asqueella]]<br />
:::::Yes, that's what I intended; (3) is not what I meant. --[[User:Mozcerize|Mozcerize]]<br />
<br />
I fully agree that <nowiki><tt></nowiki> works best in some situations, such as [[Overlays]] and [[Profile Manager]] (where you can see someone has used <nowiki><tt></nowiki> for the Windows section), and I can see why <tt><profile folder></tt> would be better for some situations. But I think there are a number of articles where this formatting doesn't work so well. Sometimes it's a little ugly and distracting, and simple quote marks do work better to communicate the idea of "a file/folder named X". See mockups below. I'd prefer a little flexibility in this style guideline, depending on the context in which the folder/file names appear. --[[User:Wintogreen|Wintogreen]] 23:03, 29 Mar 2005 (PST)<br />
<br />
====(1) Currently existing text, "as is", from [[Profile backup]]====<br />
# Completely close all Mozilla programs, including the Mozilla Suite, Firefox, and Thunderbird. Don't forget to exit the Mozilla Suite's Quick Launch if it's open (as indicated in the Windows system tray).<br />
# Find your [[profile folder]]. Go up in the folder hierarchy until you see the folder that contains the folder "Profiles" and the files "pluginreg.dat", "registry.dat", and "profiles.ini" (not all files may exist). Go up once again and copy this entire folder. For the Mozilla Suite, Firefox, or Thunderbird, this folder's name should be "Mozilla", "Firefox", or "Thunderbird", respectively.<br />
# Copy (but not move) your entire profile folder to another location.<br />
<br />
====(2) Using <nowiki><tt></nowiki> without quote marks====<br />
# Completely close all Mozilla programs, including the Mozilla Suite, Firefox, and Thunderbird. Don't forget to exit the Mozilla Suite's Quick Launch if it's open (as indicated in the Windows system tray).<br />
# Find your [[profile folder]]. Go up in the folder hierarchy until you see the folder that contains the folder <tt>Profiles</tt> and the files <tt>pluginreg.dat</tt>, <tt>registry.dat</tt>, and <tt>profiles.ini</tt> (not all files may exist). Go up once again and copy this entire folder. For the Mozilla Suite, Firefox, or Thunderbird, this folder's name should be <tt>Mozilla</tt>, <tt>Firefox</tt>, or <tt>Thunderbird</tt>, respectively.<br />
# Copy (but not move) your entire profile folder to another location.<br />
<br />
====(3) Using <nowiki><tt></nowiki> plus <profile folder>without quote marks====<br />
# Completely close all Mozilla programs, including the Mozilla Suite, Firefox, and Thunderbird. Don't forget to exit the Mozilla Suite's Quick Launch if it's open (as indicated in the Windows system tray).<br />
# Find your <tt><[[profile folder]]></tt>. Go up in the folder hierarchy until you see the folder that contains the folder <tt>Profiles</tt> and the files <tt>pluginreg.dat</tt>, <tt>registry.dat</tt>, and <tt>profiles.ini</tt> (not all files may exist). Go up once again and copy this entire folder. For the Mozilla Suite, Firefox, or Thunderbird, this folder's name should be <tt>Mozilla</tt>, <tt>Firefox</tt>, or <tt>Thunderbird</tt>, respectively.<br />
# Copy (but not move) your entire <tt><profile folder></tt> to another location.<br />
<br />
====(4) Using <nowiki><tt></nowiki> with quote marks====<br />
# Completely close all Mozilla programs, including the Mozilla Suite, Firefox, and Thunderbird. Don't forget to exit the Mozilla Suite's Quick Launch if it's open (as indicated in the Windows system tray).<br />
# Find your [[profile folder]]. Go up in the folder hierarchy until you see the folder that contains the folder "<tt>Profiles</tt>" and the files "<tt>pluginreg.dat</tt>", <tt>registry.dat</tt>", and "<tt>profiles.ini</tt>" (not all files may exist). Go up once again and copy this entire folder. For the Mozilla Suite, Firefox, or Thunderbird, this folder's name should be "<tt>Mozilla</tt>", "<tt>Firefox</tt>", or "<tt>Thunderbird</tt>", respectively.<br />
# "Copy (but not move) your entire profile folder to another location.<br />
<br />
====Proposed style guideline====<br />
Short version:<br />
* '''Path/folder/file names''': In general, put these in <nowiki><tt></tt></nowiki> tags (e.g., <tt>C:\Program Files\Mozilla Firefox\firefox.exe</tt>). In some situations, however, especially in less-technical articles, it may look better to use simple quotation marks (e.g., "Go to your profile folder and find the "chrome" folder"). Use your best judgment, depending on the context and readability.<br />
<br />
Long version:<br />
* '''Path/folder/file names''': In general, put these in <nowiki><tt></nowiki> tags (e.g., <tt>C:\Program Files\Mozilla Firefox\firefox.exe</tt>). In some situations, however, especially in less-technical articles, it may look better to use simple quotation marks (e.g., "Go to your profile folder and find the "chrome" folder"). Folders whose location varies are sometimes better when enclosed in angle brackets (e.g., <tt><profile folder>/chrome/overlayinfo/</tt>). Use your best judgment in all cases, depending on the context and readability.<br />
<br />
Revised version (based on Asqueela's comment above):<br />
* '''Path names''': Enclose these in <nowiki><tt></nowiki> tags so that they will appear in a monospace font (e.g., <tt>C:\Program Files\Mozilla Firefox\firefox.exe</tt>). Folders whose location varies (e.g., "profile folder" and "install folder") can be enclosed in angle brackets when part of a path (e.g., <tt><profile folder>/chrome/overlayinfo/</tt>).<br />
* '''Folder & file names''': Put these in quotation marks when they are used in a sentence but are not connected to a longer pathname (e.g., "Go to your profile folder and find the "chrome" folder").<br />
<br />
::I like this. [[User:Asqueella|asqueella]]<br />
::: Thanks again for the feedback. I'll put this in the page. --wintogreen<br />
:::: Note that Mozcerize said he doesn't like variable width+quotes because we already were are already using it for many other things. --[[User:Asqueella|asqueella]]<br />
::::: Hm, it's not clear to me if he meant paths or lone file/folder names, or both. --wintogreen<br />
:::::: Yes, that wasn't clear to me either. --[[User:Asqueella|asqueella]]<br />
:::::::Overall I like this. Personally I prefer Example 2 over Example 1 above (ie putting filenames and folder names in &lt;tt&gt; with no quotes rather than in variable+quotes) but I'm happy to compromise on this. (I definitely didn't like to see ''path'' names in variable+quotes.) I guess I prefer fixed width for lone names because, as in your examples, when you have an article which lists files that a user is supposed to be looking out for (eg for copying, renaming or whatever), he is going to look at Explorer(=File manager), jump back to the browser, look at Explorer again, etc. It's easier when glancing at the article to pick out the relevant filenames from the rest of the text when they are formatted in fixed width rather than in variable+quotes&mdash;try it with Examples (1) and (2)!. But it's a small issue. --[[User:Mozcerize|Mozcerize]] 00:19, 31 Mar 2005 (PST)<br />
:::::::: The style guide seems to assume that <nowiki><tt></nowiki> tags should be used on paths because its desireable to make them standout for readability. I understand why you want to do that in many cases, but it can cause problems. For example when your're writing a sentence that mentions a location and you don't want to draw extra attention to it. I think the prior style gudelines were better because they left some flexibility. --[[User:Tanstaafl|Tanstaafl]] 9:30PM, Jan 19 2006 (PST)<br />
::::::::: What prior style guidelines? --[[User:Wintogreen|wintogreen]] 07:22, 21 January 2006 (UTC)<br />
:::::::::: The ones just above the line "Revised version (based on Asqueela's comment above):". It includes the text "Use your best judgment in all cases, depending on the context and readability." [[User:Tanstaafl|Tanstaafl]] 22:17, 2 February 2006 (UTC)<br />
::::::::::: OK, now I see. Even though I don't much care for the <nowiki><tt></nowiki> look in general, I still prefer the "stricter" guideline. The negative fallout is minimal, whereas having a looser guideline would lend itself to greater inconsistency throughout the kb. --[[User:Wintogreen|wintogreen]] 05:09, 3 February 2006 (UTC)<br />
<br />
== File names, pt.2 ==<br />
Proposed addition: one can omit quotes when writing about a file is, um, "famous", eg. 'Add this to your user.js', but 'Open "user.js" in your profile folder'.<br />
<br />
Also I think we can live without filenames in quotes in dev. section. I feel stupid when I write 'you need to edit "install.rdf" to do that'. I think the dev section will eventually be moved to devmo anyways..<br />
<br />
We could use variant 2 from the above section, ie. with >tt<, but without quotes for that. Note, that I still think that using quotes around file names in other cases is fine.<br />
--[[User:Asqueella|asqueella]] 07:08, 17 Apr 2005 (PDT)<br />
<br />
:I agree --[[User:Mozcerize|Mozcerize]]<br />
<br />
:When I was editing a bunch of pages recently, I also felt it was overkill putting every single instance of a filename in quotes, much like linking every single instance of a term becomes an annoyance. Maybe we could amend the style guideline thus:<br />
<br />
::'''Directory & file names''': In general, put these in quotation marks when they are used in a sentence but are not connected to a longer pathname (e.g., "Go to the "chrome" folder in your profile folder and find the "userChrome.css" file"). Exceptions: you can omit the quotation marks around well-known file names (e.g., prefs.js or user.js), second and subsequent instances of a file name that appears multiple times in the same article, or file names used in Dev articles (you can use <nowiki><tt></nowiki> instead).<br />
: ''(wintogreen)''<br />
:::Nice. We'll see how it works. (I once again feel like a punctuation nazi.) --[[User:Asqueella|asqueella]] 04:01, 18 Apr 2005 (PDT)<br />
::::OK, I'll add it to the page. But... I thought hao2lian was the punctuation nazi. Or was he the grammar nazi? It gets so confusing sometimes.... --wintogreen<br />
<br />
==Links==<br />
I think something like the following should be added to the style rules. (and yes, I'm lazy, so I just copied it from another wiki) --[[User:Asqueella|asqueella]]<br />
:''Don't overdo linking. That's the extreme opposite of not linking at all. It's most convenient for authors and readers alike to link only the first occurrence of a term in a logical unit (a section of a tutorial, for instance). Since links stand out visually, they have the potential to disrupt the reader's flow and make reading a long text a pain when each and every sentence has one or more links. For example, if you mention "profile folder" several times, link only the first one, or the one that's relating to something technical, at a point where the reader might logically want to read up on the specifics.''<br />
<br />
::Good idea. Below is a somewhat shorter rewrite. --wintogreen<br />
<br />
:''Don't overdo linking. Since links stand out visually, they can disrupt the reader's flow and become a distraction rather than an aid. Try not to put the same link more than once in a single logical unit of an article (e.g., a section of a tutorial). For example, if you mention "profile folder" several times, link only the first one, or the one that's relating to something technical, at a point where the reader might logically want to read up on the specifics.''<br />
<br />
Thanks! I added your version to the article. --[[User:Asqueella|asqueella]]<br />
<br />
== Uploading Screenshots ==<br />
<br />
I would like to request the ability to upload screenshots. Images make understanding instructions a lot easier. The cases which immediately come to mind are:<br />
* How to customize the toolbars<br />
* How to modify your Privacy settings<br />
* How to edit your preferences (about:config)<br />
* How to edit your userChrome.css file<br />
* How to configure Tabbed Browsing<br />
* How to create a new Firefox profile<br />
etc.<br />
--[[User:Emte|Emte]]<br />
: You need to ask kerz about that. -[[User:Asqueella|asqueella]]<br />
<br />
<br />
== Linking to Bugzilla ==<br />
Has anyone thought up a policy for linking to Bugzilla. I'm not sure if it's appropriate to put these links in the article text, e.g. ''This is a known issue, Bug 1000'' or if it's best to just add the Bug link to the External Links section.<br />
--[[User:Gids|Gids]]<br />
<br />
:Good question. At the moment, several articles link to Bugzilla in the form '''there is a [http://bugzilla.mozilla.org/show_bug.cgi?id=261031 bug] in Firefox where if&hellip;''' which is coded as '''<nowiki>a [http://bugzilla.mozilla.org/show_bug.cgi?id=261031 bug] in Firefox</nowiki>'''. I agree that it could be inappropriate to link to such technical documentation in the text. I think it would be better to make use of footnotes in the External Links section, e.g. use '''there is a bug [[#foot1 | [1]]] in Firefox where if&hellip;''' in the text, which links to the footnote at the bottom, such as<br />
<br />
:'''<div id="foot1">[1] [http://bugzilla.mozilla.org/show_bug.cgi?id=261031 Bugzilla report 261031]</div>'''<br />
<br />
:This is coded using '''<nowiki>a bug [[#foot1 | [1]]] in Firefox</nowiki>''' and '''<nowiki><div id="foot1">[1] [http://bugzilla.mozilla.org/show_bug.cgi?id=261031 Bugzilla report 261031]</nowiki></div>'''.<br />
<br />
:Apologies for the bolding; obviously this is to indicate article code here, and shouldn&rsquo;t be used in the actual article! [[User:Mozcerize|Mozcerize]] 01:18, 13 September 2005 (PDT)<br />
<br />
==Introductory paragraphs - header or no==<br />
Compare [[Profile in use]] to [[Profile Manager]]. One had the intro the "Background" heading, the other just puts it at the top. Which is better? Personally, I like "just put it at the top".--[[User:Np|Np]] 19:49, 6 December 2005 (UTC)<br />
<br />
:I prefer to not have the intro separated from the rest of the article by the TOC, but I don't like using a meaningless header to push the intro down. Is TOC placement a wiki pref that can be easily tweaked? --[[User:Wintogreen|wintogreen]] 22:06, 6 December 2005 (UTC)<br />
<br />
::I actually prefer it that way.. it's the way Wikipedia works too. But it's not really something that can be debated, it's more personal preference. Put it to a vote?--[[User:Np|Np]] 22:46, 5 January 2006 (UTC)<br />
<br />
:::Having the intro in a background heading in [[Profile in use]] looks better than having it at the top in [[Profile Manager]]. But I've seen other cases where having it at the top looked better. I think it depends upon the length of both the intro and the TOC. I suggest we leave it to the authors best judgement. --[[User:Tanstaafl|Tanstaafl]] 9:52PM , 19 January 2006 (PMT)<br />
<br />
== Layout of headers ==<br />
<br />
IMHO the layout of headers in our kb should have more space above and below each header, to set them apart and make it easier for people to skim the page. Long KB pages look cluttered and are hard to skim.<br />
<br />
At first I thought Wikipedia used more negative space, but looking closely I see we seem to match their layout exactly. I think they just have a different kind of information to lay out, long paragraphs, while we have many lists, short paragraphs, short sections, etc.<br />
<br />
I don't know how easy it is to change the basic template, so perhaps it's not worth the time and effort. But the space is free (we're not paying for paper) and using 'negative' space for such purposes is very common.<br />
:--[[User:guanxi|guanxi]] 12:08, 19 Jan 2006 (Thu) EST<br />
<br />
:I've often wished the level 2 headers had a bit more padding on top. --[[User:Wintogreen|wintogreen]] 19:26, 19 January 2006 (UTC)<br />
<br />
==Common terms==<br />
Currently we capitalize things which we regard as proper nouns: Global Inbox, Download Manager. What do we do regarding Bookmarks, History, Download History? --[[User:Mozcerize|Mozcerize]] 17:15, 2 February 2006 (UTC)<br />
:If it's the feature of Firefox, it's capitalized. "Download Manager" is a feature. "download history" is information. You use the Download Manager to see the download history. You use the Boomark Manager to see bookmarks. You use the Preferences Dialog to change preferences.--[[User:Np|Np]] 17:46, 2 February 2006 (UTC)<br />
:: I agree: capitalize things that seem to be named product features (or major, named UI elements) but not the more generic-sounding items that are managed with these product features/UI elements. I would thus only capitalize something like "Download History" if I were quoting it in a menu sequence, such as "Tools -> Options -> Privacy -> Download History", where it's shown capitlized in the UI. --[[User:Wintogreen|wintogreen]] 17:51, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Downloads.rdf&diff=22649Talk:Downloads.rdf2006-02-03T05:06:34Z<p>Wintogreen: </p>
<hr />
<div>I think that important information has been removed if we get rid of the sentence which says that The data is deleted according to the user&rsquo;s settings for Download History. --[[User:Mozcerize|Mozcerize]] 17:11, 2 February 2006 (UTC)<br />
:I agree (even though TB in its present state doesn't provide any way to clear the file!). --[[User:Wintogreen|wintogreen]] 18:35, 2 February 2006 (UTC)<br />
::I disagree because the fact that the Download Manager might clear it belongs to a Download Manager article. We're not here to ''describe'' each feature that can change the contents of the file, but only to ''list'' them.--[[User:Np|Np]] 21:21, 2 February 2006 (UTC)<br />
<br />
In the revised intro, "...attachments are downloads" is more concise, certainly, but it doesn't sufficiently describe the file behavior in TB. I was very specific in what I wrote in the into about TB because TB writes to the file only when attachments are opened or saved (not downloaded from the server), and only when opened or saved in certain ways. E.g., if you drag the attachment from the attachments pane to the desktop, this save action does not get recorded in the file, oddly enough. The solution might be to make a separate downloads.rdf file for TB, but for now I'm going to revert the edit to keep the accurate descriptive info there. --[[User:Wintogreen|wintogreen]] 18:35, 2 February 2006 (UTC)<br />
:I've given it another shot and kept this info. But do we really want to describe the bugs in Thunderbird that cause an attachment not to be listed? --[[User:Np|Np]] 21:21, 2 February 2006 (UTC)<br />
::Thanks. Yes, insofar as we care about how downloads.rdf functions in Thunderbird, we do want to include this information. The bug in Thunderbird is that it uses this file in the first place. --[[User:Wintogreen|wintogreen]] 22:01, 2 February 2006 (UTC)<br />
:::[https://bugzilla.mozilla.org/show_bug.cgi?id=239136 Err...]--[[User:Np|Np]] 22:37, 2 February 2006 (UTC)<br />
::::Yes, I [[Attachment save slow (Thunderbird)|know]]. --[[User:Wintogreen|wintogreen]] 05:06, 3 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Template_talk:Profile-file&diff=22543Template talk:Profile-file2006-02-02T22:10:55Z<p>Wintogreen: </p>
<hr />
<div>I think this could be confusing to the reader unless we say ''how'' the article title is incorrect. Can we not use the same format as for the usual incorrect title template, i.e. state what the correct title is? Or state that "the title of this article is incorrectly capitalized"? --[[User:Mozcerize|Mozcerize]] 17:08, 2 February 2006 (UTC)<br />
<br />
:How about something like this instead:<br />
::'''{{{filename}}}''' is a file in the [[profile folder]]. Note that it is incorrectly capitalized in the title of this article due to [[Wikipedia:Wikipedia:Naming conventions (technical restrictions)|technical limitations]] in the wiki software.<br />
:That's similar to how I recently modified [[Template:Wrongtitle]]. I added "in the wiki software" so that you don't have to click on the link (and wait forever for the wikipedia page to load) to find out what "technical limitations" is referring to. I don't think we need the "do not edit" part like is in the preferences articles. I can't think of a single time someone has tried to edit the user.js or userChome article the way they do with the prefs articles (what's up with that, anyway?!). --[[User:Wintogreen|wintogreen]] 18:06, 2 February 2006 (UTC)<br />
::I'm more worried about "Delete [[downloads.rdf]] to fix your problem" -> (user) -> follow the link, press Edit, delete all contents, save.--[[User:Np|Np]] 21:24, 2 February 2006 (UTC)<br />
:::That would be funny if it weren't so easily imaginable. --[[User:Wintogreen|wintogreen]] 22:10, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Downloads.rdf&diff=22542Talk:Downloads.rdf2006-02-02T22:01:17Z<p>Wintogreen: </p>
<hr />
<div>I think that important information has been removed if we get rid of the sentence which says that The data is deleted according to the user&rsquo;s settings for Download History. --[[User:Mozcerize|Mozcerize]] 17:11, 2 February 2006 (UTC)<br />
:I agree (even though TB in its present state doesn't provide any way to clear the file!). --[[User:Wintogreen|wintogreen]] 18:35, 2 February 2006 (UTC)<br />
::I disagree because the fact that the Download Manager might clear it belongs to a Download Manager article. We're not here to ''describe'' each feature that can change the contents of the file, but only to ''list'' them.--[[User:Np|Np]] 21:21, 2 February 2006 (UTC)<br />
<br />
In the revised intro, "...attachments are downloads" is more concise, certainly, but it doesn't sufficiently describe the file behavior in TB. I was very specific in what I wrote in the into about TB because TB writes to the file only when attachments are opened or saved (not downloaded from the server), and only when opened or saved in certain ways. E.g., if you drag the attachment from the attachments pane to the desktop, this save action does not get recorded in the file, oddly enough. The solution might be to make a separate downloads.rdf file for TB, but for now I'm going to revert the edit to keep the accurate descriptive info there. --[[User:Wintogreen|wintogreen]] 18:35, 2 February 2006 (UTC)<br />
:I've given it another shot and kept this info. But do we really want to describe the bugs in Thunderbird that cause an attachment not to be listed? --[[User:Np|Np]] 21:21, 2 February 2006 (UTC)<br />
::Thanks. Yes, insofar as we care about how downloads.rdf functions in Thunderbird, we do want to include this information. The bug in Thunderbird is that it uses this file in the first place. --[[User:Wintogreen|wintogreen]] 22:01, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22529Talk:Profile folder2006-02-02T20:56:26Z<p>Wintogreen: /* downloads.rdf as a test case */</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
:::: How do you propose avoiding duplication between a issues article and the corresponding files article? For example, suppose I wrote a thunderbird issue article on how to fix problems with opening an attachment with the desired utility by deleting mimetypes.rdf. The user has a much greater chance of finding/reading the issues article and its also likely to be written for a less technical user. The solution may occasionally involve modifying more than one file in the profile. For example, http://kb.mozillazine.org/Phantom_folders has the user delete several files in the profile.<br />
<br />
::::Looking at the articles in http://kb.mozillazine.org/Category:Preferences its clear a lot of effort was spent writing them and they have usefull information, but they're not focused on solving problems. IMHO they're really reference articles. I would expect the exact same thing to occur. If it does, then we need some way (a sentence in the rules?) to discourage an author of the file article from lobotomizing the issues article and adding a link to thier article to "avoid duplication". This problem may never occur, but I'd prefer we find some way to prevent it rather than deal with it later. [[User:Tanstaafl|Tanstaafl]] 23:27, 31 January 2006 (UTC)<br />
:::::Indeed, these would be reference articles. I don't really see much duplication. The issue article would describe a problem and say "...to fix it, delete [[downloads.rdf]] in your [[profile folder]]". The reference article would say X, Y, and Z about downloads.rdf, and possibly even incluse a link back to the issue article.--[[User:Np|Np]] 02:26, 1 February 2006 (UTC)<br />
<br />
::Copied from the [[Knowledge_Base_changes]] discussion under [[Knowledge_Base_changes#New_Proposal.E2.80.94Creating_an_article_for_each_profile_file. | New Proposal—Creating an article for each profile file]]:<br />
::''However, a seperate article for each file seems like overkill, and biased towards more technically knowledgeable users. I'd prefer to see the effort put into writing more issues articles instead. However, if the consensus is to write a seperate article for each file then each file in the profile article should be linked to the corresponding article. Tanstaafl 22:35, 31 January 2006 (UTC)''<br />
:::I tend to agree that creating a separate article about each file in the profile might be "overkill" and (if patterned after the "preferences" articles) probably biased towards the technically-oriented. I was thinking more along the lines of concentrating on the files in the profile that come up all the time on the support forums when I agreed with the proposal (like downloads.rdf, mimeTypes.rdf and localstore.rdf) and then linking the new articles and existing articles that mention the files with "See also" references. However, on the original proposal, as written above, ''We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--Np 18:25, 29 January 2006 (UTC)'' ... If the idea behind writing Profile "files" articles is to replace the [[Profile_folder#Files_and_folders_in_the_profile]] section with a category listing, same as the Preferences article category listings are replacing various sections of the [[About:config entries]] article, eventually you are going to get down to the files with very little useful information to the normal user, and those articles will be solely for reference purposes. As a practical matter, these last file articles could just be "stubs" so that effort isn't wasted in finding all sorts of technical details about files that no one really needs. [[User:Alice Wyman|Alice Wyman]] 16:35, 1 February 2006 (UTC)<br />
::::So the worst that could happen is "article no one needs". And the best that could happen is "article useful for the curious and technically-minded". Sounds fine to me. There's nothing wrong in including "reference" or "technical" information in the KB as long as it's not harmful towards less technically-oriented users. Being technically minded myself, I am interested in what random files in the profile do, so I'll contribute to documenting them, just like I do with the preference articles. It's not going to take away from me writing Issues articles because I don't know of any important enough issues to be documented that I haven't documented already. Plus it's my time to spend as I wish. Others who don't care about a certain file, as with anything else, don't need to contribute. --[[User:Np|Np]] 16:57, 1 February 2006 (UTC)<br />
:::::I think the point being made was, why waste time and effort on articles with limited usefulness when it could be better spent on articles that benefit more users, such as "issues" articles. The assumption is that the pool of available editors is limited. That's why I suggested "stub" articles at the point of diminishing returns. [[User:Alice Wyman|Alice Wyman]] 17:29, 1 February 2006 (UTC) <br />
::::::You're also assuming that editors would otherwise spend time on writing issues articles. That's not true. I, for one, don't have any potential Issues articles floating around in my brain that haven't been written yet. Also, there's no boss around here so maybe I'd rather go do some forum work or extension work or whatever than write an issues article. Anyway, I don't see these articles taking a lot of time to write, based on the brainstorming for possible information. The editors will certainly realize that some files you need to yak about and other files a brief description will do, so I don't see a need to formalize that point - just leave it at their discretion.--[[User:Np|Np]] 18:18, 1 February 2006 (UTC)<br />
::::::: I don't want to split hairs over who made what assumptions. I only brought up the idea of "stub" articles because you had proposed such a detailed list of what to include in "profile files" articles under [[Talk:Profile_folder#Information included (brainstorming)]]. No big deal. Anyway, instead of all this yakking someone should just go ahead and write that "downloads.rdf" or <''number''>.s" (passwords file) article and see what comes out. [[User:Alice Wyman|Alice Wyman]] 18:54, 1 February 2006 (UTC)<br />
:::::::: Yeah, I was going to give it a shot tonight.--[[User:Np|Np]] 18:58, 1 February 2006 (UTC)<br />
<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
::::I agree with Wintogreen. Firstly, I like the idea of adding the word "folder" to the end of article titles concerning subfolders of the profile folder. Secondly, I think that adding the folder path to the article title would be a bit of an overkill, as would creating mini-categories, ''unless'' filenames are not unique within the profile folder tree. In the latter case, we have no choice but to have some method of differentiation. (Ideally, we should keep things simple; "userChrome.css" has to be better than "chrome/userChrome.css". Incidentally, I'm not big on lumping userChrome and userContent together, although I can see the benefit of not needing to teach people CSS in two separate articles; what do others think?) --[[User:Mozcerize|Mozcerize]] 16:37, 30 January 2006 (UTC)<br />
:::::I'd suggest seperate articles that link to each other, and maybe to something like http://www.mozilla.org/unix/customizing.html . Let that external link take care of teaching CSS. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
<br />
What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --[[User:Wintogreen|wintogreen]] 16:36, 30 January 2006 (UTC)<br />
<br />
:You might use a generic phrase that has the word lock such as such as lock files. A quick search for articles with lock in the title currently only returns "lock icon". Think about the comparable problem for *.s , *.w, *.mab, *.msf, *.src files and the fast load (XUL) files. The latter has been called "XUL.mfl" , "XUL FastLoad File" and "XUL.mfasl". At one time there also were "Invalid.mfasl" and/or "Aborted.mfasl" invalidated fast load files. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
::Yeah, I guess that makes sense. We could insert a blurb at the top of the category page noting that some files will be listed alphabetically according to the filename extension/suffix or whatever. --[[User:Wintogreen|wintogreen]] 09:20, 2 February 2006 (UTC)<br />
::I don't really like that idea because one of the major use cases of this category will be "what does file X do?". If you call an article "fast load file", how are people who don't know the names of the fast load file going to find it?--[[User:Np|Np]] 16:45, 2 February 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Its relationship to other files (ie whether it requires other files to work (like the password file), whether there are other places this info is stored, etc)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Whether it's feasible/advisable to manually edit it<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
::::The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. [[User:Tanstaafl|Tanstaafl]] 23:37, 31 January 2006 (UTC)<br />
:::::Why? I'd like to reiterate the point that I made elsewhere that, far from being confusing, the use of the wrongtitle template is ''essential'' in the case of these file articles where the capitalization is critical. Surely our first priority on the KB must be to keep things factually accurate. I think np's idea of creating a custom wrongtitle template for file articles is good; we can make it a little more accessible to non-technical users. --[[User:Mozcerize|Mozcerize]] 12:57, 2 February 2006 (UTC)<br />
::::::I've made a similar template.--[[User:Np|Np]] 17:03, 2 February 2006 (UTC)<br />
<br />
===downloads.rdf as a test case===<br />
See [[downloads.rdf]] --[[User:Np|Np]] 23:42, 1 February 2006 (UTC)<br />
:I've added some TB info to the article, changed the last header from "Possible issues" to "Related issues", and bolded the filename in the first sentence to make it (and the correct capitalization) stand out. --[[User:Wintogreen|wintogreen]] 04:36, 2 February 2006 (UTC)<br />
::"Related issues" kind of implies "Issues related to this issue" to me, and the article doesn't describe an issue. But that just might be me.--[[User:Np|Np]] 16:54, 2 February 2006 (UTC)<br />
Now that we've got this file as a kind of test case, a few comments/suggestions that could pertain to future articles (--[[User:Wintogreen|wintogreen]] 14:52, 2 February 2006 (UTC)):<br />
# Some of the files that are shared between apps (esp. between Firefox and Thunderbird) might serve rather different functions or be accessed through different UI. (mimeTypes.rdf and cookies.txt are a couple others.) In the downloads.rdf article, even the seemingly straightforward phrase "download history" can have a very different meaning in the context of email (think POP), and a statement like "downloads.rdf is the only place where download history is recorded" can easily be misunderstood as well. I'm not sure what the best way to deal with this in the present article, but it's something we should try to keep in mind when writing/editing these articles. (And for the record, I don't know how the Suite records attachment-saving operations. Do they go into downloads.rdf as they do with Thunderbird?)<br />
:::Agreed. I think we may need application-specific articles here. If we decide to link to them from pages like [[Profile folder]], perhaps we should link to a disambiguation page where the user can choose which application he is interested in. --[[User:Mozcerize|Mozcerize]]<br />
::::That may be the best solution, and I don't think it would have to be used with more than a small handful of articles. --[[User:Wintogreen|wintogreen]] 20:56, 2 February 2006 (UTC)<br />
# The section about "Disabling": does it belong in this article? To my mind, it's essentially addressing a question about how to control the application behavior ("How can I stop Firefox from recording my downloads?"), and I thus think it should go into a regular article about managing download history, the Clear Private Data tool, or browser privacy. Even if there is no such regular article, it doesn't mean that the info should go into an existing "Profile file" article. More generally speaking, I think this relates to the concern Tanstaafl expressed earlier about the potential for these "Profile file" articles to the "lobotomize" the Issues [and other regular] articles.<br />
#:Yeah, I didn't think that belonged. Including a link to an article that describes it would be better.--[[User:Np|Np]] 16:54, 2 February 2006 (UTC)<br />
:::This section may not belong in the article. I put it there to test the water. I agree that it would be better to put it into another article about browser privacy. Regarding your other point, let's not forget that Issues articles are supposed to provide "a different view" on existing information. I would be unhappy to see useful information tucked away in Issues articles without being accessible via non--Issues articles. --[[User:Mozcerize|Mozcerize]]<br />
:::: Every Issues article is is supposed to be categorized in a non-Issues category anyway, so that shouldn't be a problem... as long as we remember to follow our categorization rules. --[[User:Wintogreen|wintogreen]] 20:56, 2 February 2006 (UTC)<br />
# In the same vein, I don't think these articles should be categorized together with the regular end-user articles (currently this one is in the "Privacy and security" category). As reference articles, they should be treated essentially like the Preferences articles.<br />
#:Agree. --[[User:Np|Np]] 16:54, 2 February 2006 (UTC)<br />
::: I agree. In this vein, though, I don't see a problem if these articles are slightly more technical than the normal user support articles. --[[User:Mozcerize|Mozcerize]]<br />
::::Aye. I think if would be great if, for instance, some of these articles explained the anatomy of the file content. --[[User:Wintogreen|wintogreen]] 20:56, 2 February 2006 (UTC) <br />
<br />
Do we really need "Related mechanisms" if there are no related mechanisms? I think people would assume that when we say that the file contains download history that it is the only thing that contains download history. I don't know what the last three sentences are there for, either.--[[User:Np|Np]] 16:54, 2 February 2006 (UTC)<br />
:If the point about Disabling is to be moved to another article, then so should the last three sentences. I can't make up my mind about the Related Mechanisms section. I think the fact that it is the only mechanism dealing with download logging is an important piece of information. --[[User:Mozcerize|Mozcerize]]<br />
<br />
"Usage" says to me "How can the user use this file", but that's not what it describes. I think this info should go into the intro.--[[User:Np|Np]] 16:54, 2 February 2006 (UTC)<br />
:I agree. The problem is that we don't want the introduction to be too long. --[[User:Mozcerize|Mozcerize]]<br />
<br />
===How these files will affect the profile folder article===<br />
To follow up on a previous comment by Alice, what's anyone thinking about how these articles will affect the present state of the [[profile folder]] article? Is the idea to simply linkify the filenames in the currently existing table? Personally, I hope so. I think it's fine the way the prefs listed in [[about:config entries]] are being removed from the list there once they're written up and put into [[:Category:Preferences]], since the pref titles themselves are generally descriptive enough to give you an idea of what the pref is for, but this isn't so true with the profile files. I like having the big list of files all on one page--each with very short description--so that you can scan through it quickly. --[[User:Wintogreen|wintogreen]] 15:07, 2 February 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)<br />
::I understand the logic of removing it, but it is hard to find usefull information and we don't have a good alternative place to tell somebody about it if they don't know the file exists. Perhaps we need an article describing the layout of the thunderbird program directory which identifies any usefull files (including ones you might need to tinker with if you have a problem), and then add it to "see also" in the profile article. [[User:Tanstaafl|Tanstaafl]] 22:22, 31 January 2006 (UTC)<br />
::: Sounds like a good idea. We could link to it in the [[Installation directory]] article as well. --[[User:Wintogreen|wintogreen]] 09:22, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Phantom_folders&diff=22527Phantom folders2006-02-02T19:30:15Z<p>Wintogreen: cat</p>
<hr />
<div>{{Tbsuite}}<br />
<br />
<br />
Thunderbird can list a empty non-existent folder in the folder pane. If this occurs exit Thunderbird, [[profile backup|back up]] your profile and:<br />
<br />
:* Delete the "panacea.dat" file in your [[profile folder]]. It's a mail folder cache.<br />
:* Delete the ".msf" (mail summary file) file for that folder in the account's directory in your profile. Thunderbird believes a folder exists as long as it sees a file with the folder's name and an .msf file extension. If it's easier you could delete all .msf files. The only damage you could do is lose a [[Saved Search]] folder.<br />
:* Delete "XUL.mfl". It's a cache of user interface data.<br />
:*If you're using an [[IMAP]] account, [[Session logging for mail/news | enable IMAP logging]] and look in the log file to see whether the IMAP server returns that folder name. That helps identify whether the phantom folder is due to the client or the server. If its a UNIX IMAP server you might also check whether a ".mailboxlist" and/or ".mlbxlsttmp" file in your root directory mentions the phantom folder.<br />
<br />
Thunderbird will create a new panacea.dat, XUL.mfl, and *.msf file(s) if they're missing the next time you run it. <br />
<br />
If none of this helps, use the [[Profile Manager]] to create a new profile and then [[Migrating settings to a new profile | migrate your folders, address books and settings to it]]. Don't just copy all of the files from your old profile to it or you'll migrate the phantom folder too.<br />
<br />
[[Category:Issues (Thunderbird)]]<br />
[[Category:Mail (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=MozillaZine_Knowledge_Base:Formatting&diff=22526MozillaZine Knowledge Base:Formatting2006-02-02T19:03:22Z<p>Wintogreen: /* Linking to another Knowledge Base page */</p>
<hr />
<div>{{org}}<br />
== Links ==<br />
This is quite easy. Use double <nowiki>[[ ]]</nowiki> or single <nowiki>[ ]</nowiki> brackets, depending on whether you are linking to another page within the Knowledge Base or to an external site.<br />
<br />
=== Linking to another Knowledge Base page ===<br />
* Put the exact name of the page inside double brackets. Example: <tt><nowiki>[[Rules]]</nowiki></tt> = [[Rules]].<br />
* If the page name contains two or more separate words, write the words separated by a space rather than connected with an underline. Example: use <tt><nowiki>[[Profile Manager]]</nowiki></tt> and not <tt><nowiki>[[Profile_Manager]]</nowiki></tt> to create [[Profile Manager]].<br />
* Be careful about capital letters. Example: to link to the [[Global Inbox]] article, you need to use <tt><nowiki>[[Global Inbox]]</nowiki></tt> and not <tt><nowiki>[[Global inbox]]</nowiki></tt>.<br />
* Lowercase can be used for the first letter in the page name. Example: &ldquo;<tt><nowiki>Read the [[rules]] for editing</nowiki></tt>&rdquo; = &ldquo;Read the [[rules]] for editing&rdquo;. <br />
* To use different display text for the link, insert the pipe character "|" followed by the text you want to show for the link. Example: <tt><nowiki>[[Rules | rules for editing]]</nowiki></tt> = [[Rules | rules for editing]].<br />
* Pipe trick: for a page name ending with text in parentheses, if you insert the pipe character "|" without any text following it, the text in parentheses will not be displayed in the link. Examples: <tt><nowiki>[[Filters (Thunderbird)|]]</nowiki></tt> = [[Filters (Thunderbird)|Filters]].<br />
* It's possible to link to a specific section in a Knowledge Base page using this syntax: <tt><nowiki>[[page name#section name | display text]]</nowiki></tt>. Example: <tt><nowiki>[[In-house style#Commonly used names | Application and OS names]]</nowiki></tt> = [[In-house style#Commonly used names | Application and OS names]]. For a section in the current page you can omit the page name. Example: <tt><nowiki>[[#Document structure | Headers and lists]]</nowiki></tt> = [[#Document structure | Headers and lists]]. However, be aware that such a link will no longer lead to the specified section if someone edits the target page and changes the section name.<br />
<br />
=== Linking to an external site===<br />
Use the following syntax when linking to a page outside the Knowledge Base.<br />
* Numbered external links: <tt><nowiki>[http://mozilla.org/]</nowiki></tt> = [http://mozilla.org/].<br />
* Named external links: <tt><nowiki>[http://mozilla.org/ Mozilla Home]</nowiki></tt> = [http://mozilla.org/ Mozilla Home].<br />
* Explicit external links: &ldquo;<tt><nowiki>visit http://mozilla.org/ now</nowiki></tt>&rdquo; = &ldquo;visit http://mozilla.org/ now&rdquo;.<br />
<br />
==Document structure==<br />
===Headers===<br />
Section headers within a page are made by putting two or three equal signs on each side of the desired header text: use "==" for a level 2 header or "===" for a level 3 header. Example: in the "Links" section above, the headers were made by inserting the following: <br />
<br />
<tt><br />
<nowiki>== Links ==</nowiki><br><br />
<nowiki>=== Linking to another Knowledge Base page ===</nowiki><br><br />
<nowiki>=== Linking to an external site ===</nowiki><br />
</tt><br />
<br />
There are actually six levels of headers that can be created in the same fashion, but most articles in the Knowledge Base use only level 2 and level 3 headers. <br />
<br />
===Lists===<br />
<br />
Put <nowiki>*</nowiki> or <nowiki>#</nowiki> at the beginning of a line to make an unordered (bulleted) or ordered (numbered) list, respectively. To make a list within a list, use <nowiki>**</nowiki> or <nowiki>##</nowiki> instead. Examples:<br />
<br />
<tt><br />
<nowiki>* list item 1</nowiki><br><br />
<nowiki>* list item 2</nowiki><br><br />
<nowiki>** list item 2a</nowiki><br><br />
<nowiki>** list item 2b</nowiki><br><br />
<nowiki>* list item 3</nowiki><br />
</tt><br />
<br />
will produce<br />
<br />
* list item 1<br />
* list item 2<br />
** list item 2a<br />
** list item 2b<br />
* list item 3<br />
<br />
Whereas using <nowiki>#</nowiki> instead of <nowiki>*</nowiki> will produce<br />
<br />
# list item 1<br />
# list item 2<br />
## list item 2a<br />
## list item 2b<br />
# list item 3 <br />
<br />
===Indented text===<br />
<br />
Indenting is used most often in [[Talk]] pages. To indent a line, put a : (colon) at the beginning of the line. For example:<br />
<br />
<tt><br />
<nowiki>:Hello, I am the first indented line.</nowiki><br><br />
<nowiki>:I am the next indented line.</nowiki><br><br />
<nowiki>::I am a doubly indented line.</nowiki><br />
</tt><br />
<br />
produces<br />
<br />
:Hello, I am the first indented line.<br />
:I am the next indented line.<br />
::I am a doubly indented line.<br />
<br />
===Tables===<br />
Tables are explained on a [[MozillaZine Knowledge Base:Tables | separate page]].<br />
<br />
==Character formatting==<br />
<br />
===Emphasis===<br />
Although the current [[In-house style | style guidelines]] say that italics and bold should be used as sparingly as possible, there are some situations when you may want to use them. To do so:<br />
<br />
*<tt><nowiki>''Two single quotes''</nowiki></tt> = ''Two single quotes''<br />
*<tt><nowiki>'''Three single quotes'''</nowiki></tt> = '''Three single quotes'''<br />
*<tt><nowiki>'''''Five single quotes'''''</nowiki></tt> = '''''Five single quotes'''''<br />
<br />
===Code===<br />
<br />
Code may be entered as monospace lines by beginning each line with a space. For example:<br />
<br />
<tt><nowiki>&nbsp;user_pref("mail.ui.display.dateformat.default", 2);</nowiki></tt><br />
<br />
produces<br />
<br />
user_pref("mail.ui.display.dateformat.default", 2);<br />
<br />
This will preserve manually inserted spacing within your text, as in this example:<br />
<br />
for(int a=0;a<1;a++)<br />
{<br />
do_something();<br />
}<br />
<br />
For longer, multiline blocks of code, instead of beginning each line with a space, the preferred way is to enclose the whole block of code in a single set of &lt;pre&gt; tags. Also note that HTML and Wiki-code are still processed in monospace lines.<br />
<br />
== Signatures ==<br />
<br />
Though signatures are not used in regular Knowledge Base articles, it helpful if you include your signature when commenting in a [[Talk]] page, so that people reading the Talk page later can understand who said what when. To insert your signature:<br />
<br />
* Nickname and date: <tt><nowiki>~~~~</nowiki></tt> = [[User:Heroist|Heroist]] 09:27, 31 Jan 2004 (PST).<br />
* Nickname only: <tt><nowiki>~~~</nowiki></tt> = [[User:Heroist|Heroist]].<br />
<br />
==More Information==<br />
More advanced editing is explained at [http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide:_Editing_overview Wikipedia's MetaWiki].</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Downloads.rdf&diff=22524Downloads.rdf2006-02-02T18:36:40Z<p>Wintogreen: reverting for now -- see Talk page</p>
<hr />
<div>''(This is an example of a profile file article. See [[Talk:Profile folder]] for discussion.)''<br />
{{profile-file|filename=downloads.rdf}}<br />
<br />
'''downloads.rdf''' is a file in the [[profile folder]]. In Firefox and Mozilla Suite, it contains download history, and its contents can be viewed and managed through the [[Download Manager]]. In Thunderbird, it contains a history of attachments opened or saved by double-clicking on files listed in the Attachments pane or by using the menu sequence "File -> Attachments -> [attachment name] -> Open". Thunderbird has no UI for viewing or managing the contents of this file.<br />
<br />
==Usage==<br />
Whenever a download is initiated, information about the download (such as the file name, URL, date and time) is written to the downloads.rdf file. This data is later deleted according to the user&rsquo;s settings for Download History.<br />
<br />
==Editing==<br />
It's not advisable to edit this file manually because of its complexity and the fact that, in Firefox and Mozilla Suite, the Download Manager provides an interface to edit it.<br />
<br />
==Moving==<br />
This file can be moved to a different profile without any extra effort.<br />
<br />
==Disabling==<br />
To completely disable download logging you can delete the contents of the download.rdf file and save it as a read-only file. This will prevent your Mozilla application from ever writing data to the file. You should still be able to perform downloads as usual. ''This works for Fx (all versions). It needs verifying for other Moz apps.''<br />
<br />
==Deleting==<br />
Deleting downloads.rdf will clear your download history. A new file will be created on start up or when the application first needs to write to the file.<br />
<br />
==Related mechanisms==<br />
downloads.rdf is the only place (including [[:Category:Preferences | preferences]]) where download history is recorded. However, if you choose to directly open a file instead of first saving it to disk, data will be logged in downloads.rdf in the usual way and the file will be downloaded to your system&rsquo;s temporary folder. The file is normally deleted from the temporary folder when you close your application. However, in the event of a crash the file will often remain.<br />
<br />
==Related issues==<br />
* [[Firefox hangs]]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=159107 Bug 159107 - page saving/downloads takes too much time (is slow) ('marooned' entries in downloads.rdf)]<br />
* [[Attachment save slow (Thunderbird)]] (also see bug link in article)<br />
<br />
[[Category:Profile contents (Firefox)]]<br />
[[Category:Profile contents (Thunderbird)]]<br />
[[Category:Profile contents (Mozilla Suite)]]<br />
[[Category:Privacy and security]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Downloads.rdf&diff=22523Talk:Downloads.rdf2006-02-02T18:35:25Z<p>Wintogreen: </p>
<hr />
<div>I think that important information has been removed if we get rid of the sentence which says that The data is deleted according to the user&rsquo;s settings for Download History. --[[User:Mozcerize|Mozcerize]] 17:11, 2 February 2006 (UTC)<br />
:I agree (even though TB in its present state doesn't provide any way to clear the file!). --[[User:Wintogreen|wintogreen]] 18:35, 2 February 2006 (UTC)<br />
<br />
<br />
In the revised intro, "...attachments are downloads" is more concise, certainly, but it doesn't sufficiently describe the file behavior in TB. I was very specific in what I wrote in the into about TB because TB writes to the file only when attachments are opened or saved (not downloaded from the server), and only when opened or saved in certain ways. E.g., if you drag the attachment from the attachments pane to the desktop, this save action does not get recorded in the file, oddly enough. The solution might be to make a separate downloads.rdf file for TB, but for now I'm going to revert the edit to keep the accurate descriptive info there. --[[User:Wintogreen|wintogreen]] 18:35, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Template_talk:Profile-file&diff=22522Template talk:Profile-file2006-02-02T18:06:06Z<p>Wintogreen: </p>
<hr />
<div>I think this could be confusing to the reader unless we say ''how'' the article title is incorrect. Can we not use the same format as for the usual incorrect title template, i.e. state what the correct title is? Or state that "the title of this article is incorrectly capitalized"? --[[User:Mozcerize|Mozcerize]] 17:08, 2 February 2006 (UTC)<br />
<br />
:How about something like this instead:<br />
::'''{{{filename}}}''' is a file in the [[profile folder]]. Note that it is incorrectly capitalized in the title of this article due to [[Wikipedia:Wikipedia:Naming conventions (technical restrictions)|technical limitations]] in the wiki software.<br />
:That's similar to how I recently modified [[Template:Wrongtitle]]. I added "in the wiki software" so that you don't have to click on the link (and wait forever for the wikipedia page to load) to find out what "technical limitations" is referring to. I don't think we need the "do not edit" part like is in the preferences articles. I can't think of a single time someone has tried to edit the user.js or userChome article the way they do with the prefs articles (what's up with that, anyway?!). --[[User:Wintogreen|wintogreen]] 18:06, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:In-house_style&diff=22521Talk:In-house style2006-02-02T17:51:00Z<p>Wintogreen: /* Common terms */</p>
<hr />
<div>==Archive of resolved issues==<br />
Some of the issues discussed here seem to have been resolved for all intents and purposes, so I'm moving them to [[Talk:In-House Style/Resolved]] to clear away the clutter. --[[User:Wintogreen|Wintogreen]] 00:35, 27 Mar 2005 (PST)<br />
In particular:<br />
* Rules; article titles<br />
* Articles that apply to two or more products<br />
* Capitalization of common terms<br />
<br />
If you want to re-open one of these discussions, please do it here on this page, not on the archive page.<br />
<br />
==Application names==<br />
How do we refer to the browser included within the Mozilla Suite? Is it itself called Mozilla Suite, or do we refer to it as the "Mozilla Suite browser" or the "browser in the Mozilla Suite" or something else? Surely many articles for the Mozilla Suite pertain solely to the browser component and not to the whole suite. --[[User:Mozcerize|Mozcerize]] 05:54, 10 Apr 2005 (PDT)<br />
:I thought we'd just call it Mozilla Suite, when it's clear info only applies to the browser.--[[User:Asqueella|asqueella]]<br />
::But sometimes it's not clear: see [[increasing startup speed]] where It is not obvious which app we are talking about if we don't specify that it's the browser. --[[User:Mozcerize|Mozcerize]]<br />
<br />
I think we talked about this before, briefly, but are we sure we're going to stick with "Mozilla Suite" now that the "SeaMonkey" project has an official name? Already I see "Seamonkey" being used in one new page ([[Standard diagnostic]]). If we decide to go with SeaMonkey, it's going to be a major pain to change everything. Again. --[[User:Wintogreen|Wintogreen]] 05:51, 6 Jul 2005 (PDT)<br />
<br />
==-> vs. |==<br />
<br />
I&rsquo;m just hoping to initiate some discussion as to the relative merits of &ldquo;->&rdquo; and &ldquo;|&rdquo; for denoting menu sequences:<br />
<br />
"Tools -> Options -> Privacy -> Cookies"<br />
<br />
"Tools | Options | Privacy | Cookies"<br />
<br />
I&rsquo;ve seen both used all over the place. Also, there seems to be little concensus on what to do about tabs (eg Privacy in the the example above is the equivalent of a tab in an options dialog) and subsections (eg Cookies in the example above). Are these to be treated in the same way (ie using -> or |)? It would be useful to turn to some of the computing textbooks out there and copy what they do. Does anyone have any comments on this? --[[User:Mozcerize|Mozcerize]]<br />
<br />
:Whichever one is chosen should apply to both tabs and menus, I suppose, for consistency matters; you could add a "(tab)" parenthetical remark next to the tab to clarify matters (e.g. "Menu -> Menu -> Dialog -> General (tab)"). --hao2lian<br />
<br />
::What about the HTML entity &amp;rarr; (&rarr;)? For what it's worth, I've seen textbooks that use the pipe but never the discrete characters dash and greater-than. --[[User:Unarmed|Unarmed]] 07:02, 23 Feb 2005 (PST)<br />
<br />
:Well, &rarr; is certainly a lot nicer than ->, but the trouble is that it&rsquo;s always difficult to get people to use HTML entities, particularly when the symbol is going to be typeset frequently. The advantage of &ldquo;|&rdquo; is that it&rsquo;s very easy to type! --[[User:Mozcerize|Mozcerize]]<br />
<br />
::I vote for using "->" and if possible, install a Mediawiki hack that will replace that with a pretty arrow. We should also note on this page whether it is recommended to put spaces before and after the arrow. --asqueella<br />
<br />
:Well, if tha Mediawiki hack is possible then I vote for that too. It seems like the best compromise. --[[User:Mozcerize|Mozcerize]]<br />
<br />
==Hyphen vs. dash==<br />
PS, I totally agree with differentiating hyphens and dashes. (A pet peeve for me, too!) Now if only I can convince everyone to use single and double quotation marks (&amp;lsquo; [&lsquo;], &amp;rsquo; [&rsquo;], &amp;ldquo; [&ldquo;], &amp;rdquo; [&rdquo;]) instead of single and double neutral quotes (', " achieved using your ASCII keyboard) in every situation except marking up computer code&hellip;. Even better, will I manage to get people to use a single right quotation mark (&amp;rsquo; [&rsquo;]) instead of a single neutral quote (') or the equivalent (and hence completely misnamed) entity &amp;apos; when typing an apostrophe? :-P<br />
<br />
:kerz could be petitioned to install a Mediawiki hack to do this, since I'm sure there's one out there. --hao2lian<br />
<br />
OK, so these characters don&rsquo;t look too &ldquo;curly&rdquo; in the default font and size on Firefox, but they certainly do when you increase the text size in a couple of times&mdash;try it! Also, the difference is very obvious in smaller font sizes in serif fonts, and in the default font and size in IE. All of these suggestions are advocated by Unicode [http://www.unicode.org/versions/Unicode4.0.0/] (View the PDF for Chapter&nbsp;6, Section&nbsp;6.2, General Punctuation.) Note that the use of the entity name &lsquo;apos&rsquo; was a horrendous blunder made in the days before decent computer fonts were mainstream.<br />
--[[User:Mozcerize|Mozcerize]] 04:01, 10 Feb 2005 (PST)<br />
<br />
<br />
==Whitespace around dashes==<br />
Personally I prefer using whitespace around emdashes, especially since Gecko still doesn't properly allow linebreaks after that character.<br />
<br />
:Personally, I prefer a tiny bit of whitespace around emdashes too. However, the amount varies from publisher to publisher, and it is correctly achieved not by surrounding the emdash with inter-word spaces but simply by typesetting the emdash with some surrounding space "built in" to the character. So it's really a Gecko issue rather than a user issue. I wasn't aware that Gecko refuses to break lines after emdashes. The spacing issue is an irritant but not a bug; the line-break issue is a bug. I shall go and investigate it! --[[User:Mozcerize|Mozcerize]] 01:06, 22 Feb 2005 (PST)<br />
<br />
::I believe the issue is covered by either [https://bugzilla.mozilla.org/show_bug.cgi?id=95067 Bug 95067: line-break should be allowed after hyphens (unless followed by a number)] or [https://bugzilla.mozilla.org/show_bug.cgi?id=255990 Bug 255990: Characters below U+0100 are not subject to line breaking rules at all] --[[User:Unarmed|Unarmed]] 20:39, 26 Feb 2005 (PST)<br />
<br />
<br />
==Active voice==<br />
Unarmed, I think you mean "use the imperative" rather than "use the active voice". "Help old ladies", "helping old ladies" and "helped old ladies" are all in the active voice. --[[User:Mozcerize|Mozcerize]] 03:17, 23 Feb 2005 (PST)<br />
<br />
:Yes. I knew what I meant, but I had the incorrect term -- I just knew that it wasn't "infinitive." :) --[[User:Unarmed|Unarmed]] 06:53, 23 Feb 2005 (PST)<br />
<br />
::Ok, changed. :) --[[User:Mozcerize|Mozcerize]]<br />
<br />
Is it really a good idea? To my eye, [[Uninstalling extensions]] is better than ''Uninstall extensions'' and [[Using keyword searches]] is better than ''Use keyword searches''. The former implies there's a walk-through or a tutorial on the topic, the latter looks like you advise user to uninstall all of his extensions.<br />
--[[User:Asqueella|asqueella]]<br />
<br />
:Well, I largely agree with you asqueella. In general these things look better when the present participle is used, as in "uninstalling extensions". (The original proposal to use the imperative form was not mine. I believe Wikipedia advocate the use of the present participle too.) I would say that all in-page headings should be in this format. <br />
<br />
:For topic titles, one advantage of using the imperative is when it comes to linking one page to another. In many articles in the KB, you want to be able to say things like "If you are having trouble finding what you want, you should ''use keyword searches''" and you would be able to provide the link to "use keyword searches" simply by typing [ [use keyword searches] ]. However, you gain nothing when the first letter of the topic title is capitalized, since you would normally have to reword the link to remove the capitalization anyway.<br />
<br />
:Hence, I advocate either abandoning initial capitalization and using the imperative, or keeping initial capitalization and using the present participle.<br />
:--[[User:Mozcerize|Mozcerize]] 02:16, 26 Feb 2005 (PST)<br />
<br />
:: ''"For topic titles, one advantage of using the imperative is when it comes to linking one page to another."''<br />
:: But then you can't use accidental linking when using the participle, e.g. "[[Uninstalling extensions]] is very easy" :)<br />
:: I think that we should use present participle when appropriate '''and''' decapitalize first letters of words. --[[User:Asqueella|asqueella]]<br />
<br />
: ''"But then you can't use accidental linking when using the participle, e.g. "[[Uninstalling extensions]] is very easy" :)"''<br />
: lol, indeed :-)<br />
:I agree with your suggestion. --[[User:Mozcerize|Mozcerize]]<br />
<br />
Hmm. I say it depends on the article. To my ear, "Using Templates" sounds better than "Use Templates" but "Resend Message" sounds better than "Resending Message". So, let the page authors use their own judgment. And by the way, "infinitive" is the correct term; it's just that imperatives use the infinitive form. --wintogreen<br />
<br />
:Well, "Resend Message" sounds like it's a phrase taken from a dialog or button or something, so it should be kept unchanged. I think that outside of that context, "resending a message" sounds better that "Resend message". At the moment the KB is a mix of both, even on the same page, which is far from ideal.<br />
<br />
:BTW, "imperative" is the correct term. An infinitive in English consists (usually) of the word "to" followed by a verb form (sometimes called a ''bare infinitive''). The imperative is simply the bare infinitive (ie the infinitive with "to" removed).<br />
<br />
:--[[User:Mozcerize|Mozcerize]] 08:31, 27 Feb 2005 (PST)<br />
<br />
'''Update''': I went ahead and deleted the line about using the imperative, due to the lack of consensus here. Unless we can come up with an easily agreed upon, simply expressed guideline, I don't think there's any point in including it in the Style guide. --[[User:Wintogreen|Wintogreen]] 01:08, 27 Mar 2005 (PST)<br />
<br />
==Keyboard shortcuts==<br />
Should keyboard shortcuts like Ctrl+D be in quotes or italicized or bold? --[[User:Asqueella|asqueella]]<br />
<br />
:Ideally, someone should allow the <code>kbd</code> HTML element and we can worry about it in CSS. And while the subject is up, I propose we enclose modifier keys and function keys in brackets: [Ctrl]+D, [F7], [Shift]+[Del] --[[User:Unarmed|Unarmed]] 17:01, 26 Feb 2005 (PST)<br />
<br />
:: fwiw, I'm not fond of enclosing keys in square brackets. And it's not widely used currently. Not sure that <kbd> element is a good idea - just think about all the times you'll have to type: <kbd></kbd>... --[[User:Asqueella|asqueella]] 17:14, 26 Feb 2005 (PST)<br />
<br />
::: I could concede the brackets, but I really do feel that <code>kbd</code> is the most appropriate option here. It's also used in the internal Firefox help file. --[[User:Unarmed|Unarmed]] 20:22, 26 Feb 2005 (PST)<br />
<br />
:: I think <code>kbd</code> is appropriate, but it's going to be quite hard to enforce. Many people ''really'' don't like typing much ;-). Is there any way of using an easier ASCII structure (eg ^) to indicate keyboard input, and then get the Wiki to do its funky stuff to convert it? --[[User:Mozcerize|Mozcerize]]<br />
<br />
:::I vote for quotes, as currently in the current In-House Style page. It's easy to type, easy enough to read, and consistent with using quotes for menu hierarchy. Italics and bold should be used for emphasis, not for describing mouse movements or keystrokes. IMHO, of course. I would change my vote to <kbd> if a formatting button could be added for it; it'd be too tedious to have to type it out all the time. --wintogreen<br />
<br />
==URLs==<br />
Please don't use the syntax <nowiki>[[wikipedia:articlename]]</nowiki> to link to an article on Wikipedia, since this prevents the link from being recognized as external to the KB and hence it is not displayed with the "[http:// &nbsp;]" symbol. This is confusing for users, since ordinarily only internal links are displayed without this symbol. (The syntax exists to make Wikipedia authors' lives easier, and is available in the KB purely because this Wiki is based on the one they use.) Instead, link to Wikipedia using <nowiki>[http://www.wikipedia.org/wiki/articlename]</nowiki>.<br />
<br />
:This could be changed by removing (or changing) the <code>#bodyContent a.extiw, #bodyContent a.extiw:active</code> rule from line 538 of <code>/stylesheets/monobook/main.css</code>. --[[User:Unarmed|Unarmed]] 13:37, 8 Mar 2005 (PST)<br />
<br />
::Indeed, I've [[User talk:Hao2lian | requested]] that some such change be made to the stylesheet. --[[User:Mozcerize|Mozcerize]] 01:52, 9 Mar 2005 (PST)<br />
<br />
==plugin or plug-in==<br />
I like plugin more, and I also think it's more correct (talking about noun).<br />
Anyone has opinions on this?<br />
: hao2lian has gone ahead and replaced plug-in -> plugin on the page I was thinking about ([[Windows Media Player]]). Adding this variant to the main page, if you think this is incorrect, comment here.<br />
[[User:Asqueella|asqueella]]<br />
<br />
==moved pages with Kb: prefix back==<br />
They don't make sense. Either use a namespace or don't prefix them at all. The person who made those changes hasn't contributed recently (and only made those changes). [[User:Asqueella|asqueella]] 03:29, 29 Mar 2005 (PST)<br />
<br />
==Path, folder and file names==<br />
I think it was decided to use <nowiki><tt></nowiki> tags for these, but does that mean quote marks around the folder/file name should no longer be used (as was the original suggestion)? Here's a [[Thunderbird : FAQs : Changing Mail Storage Location|test case]] where I used <nowiki><tt></nowiki> for folder names without quotes. Doesn't look great to me. Ideas? --wintogreen<br />
:Hm, I must have missed something, but I don't remember the suggestion to use quotes around file names and paths. I remember that suggestion for keyboard shortcuts only.<br />
:About file paths, I brought this up, suggesting the use of &lt;tt&gt;, Unarmed replied saying his only requirement is using fixed-width, and nobody else commented for quite a while. To my eye, &lt;tt&gt; looks okay. Not perfect, but okay. Do you like quotes + variable width, like "profile"? [[User:Asqueella|asqueella]]<br />
::I wouldn't like to see quotes + variable width; we're already using that for several different things. I too think that fixed width is important. I also agree that it doesn't look perfect, but it's okay.<br />
::Can't remember if I've said this before, but I think folders whose location varies should be written as <tt>&lt;profile folder&gt;</tt> and <tt>&lt;install folder&gt;</tt> so that subfolders would be written as <tt>&lt;profile folder&gt;/chrome</tt> etc. If the author wishes he can link to the [[Profile folder]] article, eg <tt>&lt;[[Profile folder | profile folder]]&gt;/chrome</tt>. --[[User:Mozcerize|Mozcerize]] 15:02, 29 Mar 2005 (PST)<br />
:::Thanks for the feedback. Asquella, the original idea was to use quote marks around just file names (not folder names also; my mistake). You'll see it if you go back in the page history. Quote marks with <nowiki><tt></nowiki> actually looks OK, but I think it's formatting overkill. (I'm going to resume my comments below. No indent...) --wintogreen<br />
::::Just a quick note, I thought Mozcerize meant to use "<profile folder>" when it's part of a path only. I.e. "Find your [[profile folder]]", but "<profile folder>/chrome/chrome.rdf", so example (3) doesn't make sense.<br />
::::So I think actually what you mean is to enclose ''paths'', e.g. <tt>C:\Program Files\Mozilla Firefox</tt> or <tt><profile folder>\extensions</tt> in &lt;tt&gt; tags, but name of files/directories, like "chrome" or "cookies.txt" in parentheses. That's fine with me. &lt;tt&gt; inside quotes looks bad to me. --[[User:Asqueella|asqueella]]<br />
:::::Yes, that's what I intended; (3) is not what I meant. --[[User:Mozcerize|Mozcerize]]<br />
<br />
I fully agree that <nowiki><tt></nowiki> works best in some situations, such as [[Overlays]] and [[Profile Manager]] (where you can see someone has used <nowiki><tt></nowiki> for the Windows section), and I can see why <tt><profile folder></tt> would be better for some situations. But I think there are a number of articles where this formatting doesn't work so well. Sometimes it's a little ugly and distracting, and simple quote marks do work better to communicate the idea of "a file/folder named X". See mockups below. I'd prefer a little flexibility in this style guideline, depending on the context in which the folder/file names appear. --[[User:Wintogreen|Wintogreen]] 23:03, 29 Mar 2005 (PST)<br />
<br />
====(1) Currently existing text, "as is", from [[Profile backup]]====<br />
# Completely close all Mozilla programs, including the Mozilla Suite, Firefox, and Thunderbird. Don't forget to exit the Mozilla Suite's Quick Launch if it's open (as indicated in the Windows system tray).<br />
# Find your [[profile folder]]. Go up in the folder hierarchy until you see the folder that contains the folder "Profiles" and the files "pluginreg.dat", "registry.dat", and "profiles.ini" (not all files may exist). Go up once again and copy this entire folder. For the Mozilla Suite, Firefox, or Thunderbird, this folder's name should be "Mozilla", "Firefox", or "Thunderbird", respectively.<br />
# Copy (but not move) your entire profile folder to another location.<br />
<br />
====(2) Using <nowiki><tt></nowiki> without quote marks====<br />
# Completely close all Mozilla programs, including the Mozilla Suite, Firefox, and Thunderbird. Don't forget to exit the Mozilla Suite's Quick Launch if it's open (as indicated in the Windows system tray).<br />
# Find your [[profile folder]]. Go up in the folder hierarchy until you see the folder that contains the folder <tt>Profiles</tt> and the files <tt>pluginreg.dat</tt>, <tt>registry.dat</tt>, and <tt>profiles.ini</tt> (not all files may exist). Go up once again and copy this entire folder. For the Mozilla Suite, Firefox, or Thunderbird, this folder's name should be <tt>Mozilla</tt>, <tt>Firefox</tt>, or <tt>Thunderbird</tt>, respectively.<br />
# Copy (but not move) your entire profile folder to another location.<br />
<br />
====(3) Using <nowiki><tt></nowiki> plus <profile folder>without quote marks====<br />
# Completely close all Mozilla programs, including the Mozilla Suite, Firefox, and Thunderbird. Don't forget to exit the Mozilla Suite's Quick Launch if it's open (as indicated in the Windows system tray).<br />
# Find your <tt><[[profile folder]]></tt>. Go up in the folder hierarchy until you see the folder that contains the folder <tt>Profiles</tt> and the files <tt>pluginreg.dat</tt>, <tt>registry.dat</tt>, and <tt>profiles.ini</tt> (not all files may exist). Go up once again and copy this entire folder. For the Mozilla Suite, Firefox, or Thunderbird, this folder's name should be <tt>Mozilla</tt>, <tt>Firefox</tt>, or <tt>Thunderbird</tt>, respectively.<br />
# Copy (but not move) your entire <tt><profile folder></tt> to another location.<br />
<br />
====(4) Using <nowiki><tt></nowiki> with quote marks====<br />
# Completely close all Mozilla programs, including the Mozilla Suite, Firefox, and Thunderbird. Don't forget to exit the Mozilla Suite's Quick Launch if it's open (as indicated in the Windows system tray).<br />
# Find your [[profile folder]]. Go up in the folder hierarchy until you see the folder that contains the folder "<tt>Profiles</tt>" and the files "<tt>pluginreg.dat</tt>", <tt>registry.dat</tt>", and "<tt>profiles.ini</tt>" (not all files may exist). Go up once again and copy this entire folder. For the Mozilla Suite, Firefox, or Thunderbird, this folder's name should be "<tt>Mozilla</tt>", "<tt>Firefox</tt>", or "<tt>Thunderbird</tt>", respectively.<br />
# "Copy (but not move) your entire profile folder to another location.<br />
<br />
====Proposed style guideline====<br />
Short version:<br />
* '''Path/folder/file names''': In general, put these in <nowiki><tt></tt></nowiki> tags (e.g., <tt>C:\Program Files\Mozilla Firefox\firefox.exe</tt>). In some situations, however, especially in less-technical articles, it may look better to use simple quotation marks (e.g., "Go to your profile folder and find the "chrome" folder"). Use your best judgment, depending on the context and readability.<br />
<br />
Long version:<br />
* '''Path/folder/file names''': In general, put these in <nowiki><tt></nowiki> tags (e.g., <tt>C:\Program Files\Mozilla Firefox\firefox.exe</tt>). In some situations, however, especially in less-technical articles, it may look better to use simple quotation marks (e.g., "Go to your profile folder and find the "chrome" folder"). Folders whose location varies are sometimes better when enclosed in angle brackets (e.g., <tt><profile folder>/chrome/overlayinfo/</tt>). Use your best judgment in all cases, depending on the context and readability.<br />
<br />
Revised version (based on Asqueela's comment above):<br />
* '''Path names''': Enclose these in <nowiki><tt></nowiki> tags so that they will appear in a monospace font (e.g., <tt>C:\Program Files\Mozilla Firefox\firefox.exe</tt>). Folders whose location varies (e.g., "profile folder" and "install folder") can be enclosed in angle brackets when part of a path (e.g., <tt><profile folder>/chrome/overlayinfo/</tt>).<br />
* '''Folder & file names''': Put these in quotation marks when they are used in a sentence but are not connected to a longer pathname (e.g., "Go to your profile folder and find the "chrome" folder").<br />
<br />
::I like this. [[User:Asqueella|asqueella]]<br />
::: Thanks again for the feedback. I'll put this in the page. --wintogreen<br />
:::: Note that Mozcerize said he doesn't like variable width+quotes because we already were are already using it for many other things. --[[User:Asqueella|asqueella]]<br />
::::: Hm, it's not clear to me if he meant paths or lone file/folder names, or both. --wintogreen<br />
:::::: Yes, that wasn't clear to me either. --[[User:Asqueella|asqueella]]<br />
:::::::Overall I like this. Personally I prefer Example 2 over Example 1 above (ie putting filenames and folder names in &lt;tt&gt; with no quotes rather than in variable+quotes) but I'm happy to compromise on this. (I definitely didn't like to see ''path'' names in variable+quotes.) I guess I prefer fixed width for lone names because, as in your examples, when you have an article which lists files that a user is supposed to be looking out for (eg for copying, renaming or whatever), he is going to look at Explorer(=File manager), jump back to the browser, look at Explorer again, etc. It's easier when glancing at the article to pick out the relevant filenames from the rest of the text when they are formatted in fixed width rather than in variable+quotes&mdash;try it with Examples (1) and (2)!. But it's a small issue. --[[User:Mozcerize|Mozcerize]] 00:19, 31 Mar 2005 (PST)<br />
:::::::: The style guide seems to assume that <nowiki><tt></nowiki> tags should be used on paths because its desireable to make them standout for readability. I understand why you want to do that in many cases, but it can cause problems. For example when your're writing a sentence that mentions a location and you don't want to draw extra attention to it. I think the prior style gudelines were better because they left some flexibility. --[[User:Tanstaafl|Tanstaafl]] 9:30PM, Jan 19 2006 (PST)<br />
::::::::: What prior style guidelines? --[[User:Wintogreen|wintogreen]] 07:22, 21 January 2006 (UTC)<br />
<br />
== File names, pt.2 ==<br />
Proposed addition: one can omit quotes when writing about a file is, um, "famous", eg. 'Add this to your user.js', but 'Open "user.js" in your profile folder'.<br />
<br />
Also I think we can live without filenames in quotes in dev. section. I feel stupid when I write 'you need to edit "install.rdf" to do that'. I think the dev section will eventually be moved to devmo anyways..<br />
<br />
We could use variant 2 from the above section, ie. with >tt<, but without quotes for that. Note, that I still think that using quotes around file names in other cases is fine.<br />
--[[User:Asqueella|asqueella]] 07:08, 17 Apr 2005 (PDT)<br />
<br />
:I agree --[[User:Mozcerize|Mozcerize]]<br />
<br />
:When I was editing a bunch of pages recently, I also felt it was overkill putting every single instance of a filename in quotes, much like linking every single instance of a term becomes an annoyance. Maybe we could amend the style guideline thus:<br />
<br />
::'''Directory & file names''': In general, put these in quotation marks when they are used in a sentence but are not connected to a longer pathname (e.g., "Go to the "chrome" folder in your profile folder and find the "userChrome.css" file"). Exceptions: you can omit the quotation marks around well-known file names (e.g., prefs.js or user.js), second and subsequent instances of a file name that appears multiple times in the same article, or file names used in Dev articles (you can use <nowiki><tt></nowiki> instead).<br />
: ''(wintogreen)''<br />
:::Nice. We'll see how it works. (I once again feel like a punctuation nazi.) --[[User:Asqueella|asqueella]] 04:01, 18 Apr 2005 (PDT)<br />
::::OK, I'll add it to the page. But... I thought hao2lian was the punctuation nazi. Or was he the grammar nazi? It gets so confusing sometimes.... --wintogreen<br />
<br />
==Links==<br />
I think something like the following should be added to the style rules. (and yes, I'm lazy, so I just copied it from another wiki) --[[User:Asqueella|asqueella]]<br />
:''Don't overdo linking. That's the extreme opposite of not linking at all. It's most convenient for authors and readers alike to link only the first occurrence of a term in a logical unit (a section of a tutorial, for instance). Since links stand out visually, they have the potential to disrupt the reader's flow and make reading a long text a pain when each and every sentence has one or more links. For example, if you mention "profile folder" several times, link only the first one, or the one that's relating to something technical, at a point where the reader might logically want to read up on the specifics.''<br />
<br />
::Good idea. Below is a somewhat shorter rewrite. --wintogreen<br />
<br />
:''Don't overdo linking. Since links stand out visually, they can disrupt the reader's flow and become a distraction rather than an aid. Try not to put the same link more than once in a single logical unit of an article (e.g., a section of a tutorial). For example, if you mention "profile folder" several times, link only the first one, or the one that's relating to something technical, at a point where the reader might logically want to read up on the specifics.''<br />
<br />
Thanks! I added your version to the article. --[[User:Asqueella|asqueella]]<br />
<br />
== Uploading Screenshots ==<br />
<br />
I would like to request the ability to upload screenshots. Images make understanding instructions a lot easier. The cases which immediately come to mind are:<br />
* How to customize the toolbars<br />
* How to modify your Privacy settings<br />
* How to edit your preferences (about:config)<br />
* How to edit your userChrome.css file<br />
* How to configure Tabbed Browsing<br />
* How to create a new Firefox profile<br />
etc.<br />
--[[User:Emte|Emte]]<br />
: You need to ask kerz about that. -[[User:Asqueella|asqueella]]<br />
<br />
<br />
== Linking to Bugzilla ==<br />
Has anyone thought up a policy for linking to Bugzilla. I'm not sure if it's appropriate to put these links in the article text, e.g. ''This is a known issue, Bug 1000'' or if it's best to just add the Bug link to the External Links section.<br />
--[[User:Gids|Gids]]<br />
<br />
:Good question. At the moment, several articles link to Bugzilla in the form '''there is a [http://bugzilla.mozilla.org/show_bug.cgi?id=261031 bug] in Firefox where if&hellip;''' which is coded as '''<nowiki>a [http://bugzilla.mozilla.org/show_bug.cgi?id=261031 bug] in Firefox</nowiki>'''. I agree that it could be inappropriate to link to such technical documentation in the text. I think it would be better to make use of footnotes in the External Links section, e.g. use '''there is a bug [[#foot1 | [1]]] in Firefox where if&hellip;''' in the text, which links to the footnote at the bottom, such as<br />
<br />
:'''<div id="foot1">[1] [http://bugzilla.mozilla.org/show_bug.cgi?id=261031 Bugzilla report 261031]</div>'''<br />
<br />
:This is coded using '''<nowiki>a bug [[#foot1 | [1]]] in Firefox</nowiki>''' and '''<nowiki><div id="foot1">[1] [http://bugzilla.mozilla.org/show_bug.cgi?id=261031 Bugzilla report 261031]</nowiki></div>'''.<br />
<br />
:Apologies for the bolding; obviously this is to indicate article code here, and shouldn&rsquo;t be used in the actual article! [[User:Mozcerize|Mozcerize]] 01:18, 13 September 2005 (PDT)<br />
<br />
==Introductory paragraphs - header or no==<br />
Compare [[Profile in use]] to [[Profile Manager]]. One had the intro the "Background" heading, the other just puts it at the top. Which is better? Personally, I like "just put it at the top".--[[User:Np|Np]] 19:49, 6 December 2005 (UTC)<br />
<br />
:I prefer to not have the intro separated from the rest of the article by the TOC, but I don't like using a meaningless header to push the intro down. Is TOC placement a wiki pref that can be easily tweaked? --[[User:Wintogreen|wintogreen]] 22:06, 6 December 2005 (UTC)<br />
<br />
::I actually prefer it that way.. it's the way Wikipedia works too. But it's not really something that can be debated, it's more personal preference. Put it to a vote?--[[User:Np|Np]] 22:46, 5 January 2006 (UTC)<br />
<br />
:::Having the intro in a background heading in [[Profile in use]] looks better than having it at the top in [[Profile Manager]]. But I've seen other cases where having it at the top looked better. I think it depends upon the length of both the intro and the TOC. I suggest we leave it to the authors best judgement. --[[User:Tanstaafl|Tanstaafl]] 9:52PM , 19 January 2006 (PMT)<br />
<br />
== Layout of headers ==<br />
<br />
IMHO the layout of headers in our kb should have more space above and below each header, to set them apart and make it easier for people to skim the page. Long KB pages look cluttered and are hard to skim.<br />
<br />
At first I thought Wikipedia used more negative space, but looking closely I see we seem to match their layout exactly. I think they just have a different kind of information to lay out, long paragraphs, while we have many lists, short paragraphs, short sections, etc.<br />
<br />
I don't know how easy it is to change the basic template, so perhaps it's not worth the time and effort. But the space is free (we're not paying for paper) and using 'negative' space for such purposes is very common.<br />
:--[[User:guanxi|guanxi]] 12:08, 19 Jan 2006 (Thu) EST<br />
<br />
:I've often wished the level 2 headers had a bit more padding on top. --[[User:Wintogreen|wintogreen]] 19:26, 19 January 2006 (UTC)<br />
<br />
==Common terms==<br />
Currently we capitalize things which we regard as proper nouns: Global Inbox, Download Manager. What do we do regarding Bookmarks, History, Download History? --[[User:Mozcerize|Mozcerize]] 17:15, 2 February 2006 (UTC)<br />
:If it's the feature of Firefox, it's capitalized. "Download Manager" is a feature. "download history" is information. You use the Download Manager to see the download history. You use the Boomark Manager to see bookmarks. You use the Preferences Dialog to change preferences.--[[User:Np|Np]] 17:46, 2 February 2006 (UTC)<br />
:: I agree: capitalize things that seem to be named product features (or major, named UI elements) but not the more generic-sounding items that are managed with these product features/UI elements. I would thus only capitalize something like "Download History" if I were quoting it in a menu sequence, such as "Tools -> Options -> Privacy -> Download History", where it's shown capitlized in the UI. --[[User:Wintogreen|wintogreen]] 17:51, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Password-protected_profile&diff=22507Password-protected profile2006-02-02T16:06:51Z<p>Wintogreen: /* See also */ apostrophe</p>
<hr />
<div>If you wish to password-protect your profile, so that others will not be able to use your profile unless they know the password, you can do so using an extension listed below. Note that this will '''not''' provide a high level of security, especially from advanced users, but it should be sufficient to keep casual users from accessing your profile.<br />
<br />
==Thunderbird==<br />
For Thunderbird there are two different extensions you can use.<br />
* [http://www.extensionsmirror.nl/index.php?showtopic=1801 ProfilePassword] puts a simple lock on your profile. See the extension author's [https://nic-nac-project.de/~kaosmos/profilepassword-en.html homepage] for further information on security limitations when using this extension.<br />
* [http://www.supportware.net/mozilla/#ext14 DiddlyDo] will let you password-protect the whole profile and/or selected folders. The extension author has left the user interface deliberately vague, but see this [http://forums.mozillazine.org/viewtopic.php?p=1506958#1506958 forum thread] for a few usage hints.<br />
<br />
If you do not know how to install an extension in Thunderbird, [[Extensions (Thunderbird) | read this]].<br />
<br />
==Firefox==<br />
To password-protect your Firefox profile, you can use the [http://www.extensionsmirror.nl/index.php?showtopic=2179 ProfilePassword] extension. See the extension author's [https://nic-nac-project.de/~kaosmos/profilepassword-en.html homepage] for further information on security limitations when using this extension.<br />
<br />
==See also==<br />
* [[Master password | Using a Master Password]] to protect your stored passwords in Firefox, Thunderbird, or Mozilla Suite.<br />
* [[Protect the profiles contents | Protecting the profile's contents]]: several more secure alternatives.<br />
[[Category:Privacy and security]]<br />
[[Category:Profiles]]<br />
[[Category:Privacy and security (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Protecting_the_contents_of_the_profile_-_mail&diff=22506Protecting the contents of the profile - mail2006-02-02T16:04:27Z<p>Wintogreen: tidying; putting links in context; also, let's not explicity *tell* people how to bypass password-protection extensions</p>
<hr />
<div>{{Tbsuite}}<br />
<br />
<br />
All of your messages are normally stored in text files within your [[profile folder]]. Somebody else could read them using Thunderbird or by viewing the appropiate file with a text editor. If you want to prevent this the first thing you need to do is decide how much effort to protect your messages is appropiate. '''The easiest option is to password-protect the profile with an extension, but this provides only a low level of protection.''' <br />
<br />
Several methods to consider:<br />
<br />
* Install an [[Password-protected profile | extension that requires a password]] in order to use the profile. This method may be sufficient if the other people accessing the same computer are not very technically inclined or if they are unlikely to deliberately snoop.<br />
<br />
* If you have multiple users on a machine as a minimum create a separate Windows user account for each person, and then use the Thunderbird [[Profile Manager]] to create each person's profile somewhere other than the default location. This makes it harder to accidentally stumble across each other's profiles.<br />
<br />
* Use operating system commands to restrict access to the files. For example, if you store your profile on a NTFS partition under Windows 2000 or XP you can right-click on the folder in Windows Explorer, select Properties, [http://windows.about.com/od/tipsarchive/l/bltip542.htm the Security tab], and then specify who has access to that folder. That can be bypassed by somebody else with admin privileges, or by booting another operating system using a live CD such as Knoppix. In a business environment an admin might consider using group or system policy settings to restrict access or store it in password-protected file share on a file server. <br />
<br />
* [[Running from a USB drive (Thunderbird)|Store the profile on a USB/flash disk]]. They frequently support requiring a password to access the contents, and you can always remove the USB/flash disk.<br />
<br />
* Use an [[IMAP]] account. By default, IMAP stores messages on remote folders which you can access as if they're local folders. This doesn't protect your address book or other files in your profile, but it does simplify things since it does not download the message body to your hard disk, even when you're reading it. Somebody could still use any passwords you stored in the Password Manager unless you set a [[master password]].<br />
<br />
* Store the profile on a password-protected encrypted disk partition. This is the most secure solution. You want to use a encrypted disk partition to avoid being prompted to encrypt and decrypt each file. If you're running the Pro version of Windows 2000 or XP you can use the [http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prnb_efs_qutx.asp Microsoft EFS (Encrypted File System) file system]. You could also use the free version of [http://www.pgpi.org/products/pgpdisk/ pgpdisk] , [http://axcrypt.sourceforge.net/ Axcrypt] or [http://www.truecrypt.org/ TrueCrypt]. If you're running Linux there are many ways to encrypt a partition such as [http://koeln.ccc.de/archiv/drt/crypto/ppdd.man.html pppd - Practical Privacy Disc Driver].<br />
<br />
If you're fanatic about privacy:<br />
<br />
* Think about where your temporary files are stored. Thunderbird creates two temporary files when sending a message. Opening an attachment will also typically create a temporary file. Under Windows you can set the TMP and TEMP environmental variables to point to where temporary files should be created. You might set it to a small RAM disk or a directory in an existing password-protected encrypted disk partition. <br />
<br />
* If you delete a message stored in your POP account or Local Folders directory the original message is still in that folder (just hidden from view and marked for deletion). When you [[compacting folders |compact a folder]] it physically deletes the "deleted" messages. It creates a [[Nstmp folders | temporary "nstmp" file]] and then deletes it when it does this. You'd need to use a secure data removal tool to prevent somebody from using a disk editor to read the sectors used to store those messages. However, if you stored the profile on a password-protected encrypted disk partition the messages in the freed sectors should still be encrypted, not clear text.<br />
<br />
==External links==<br />
* [http://www.tolvanen.com/eraser/ Eraser - a secure data removal tool].<br />
<br />
[[Category:Privacy and security]]<br />
[[Category:Profiles]]<br />
[[Category:Privacy and security (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22505Talk:Profile folder2006-02-02T15:07:13Z<p>Wintogreen: /* How these files will affect the profile folder article */</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
:::: How do you propose avoiding duplication between a issues article and the corresponding files article? For example, suppose I wrote a thunderbird issue article on how to fix problems with opening an attachment with the desired utility by deleting mimetypes.rdf. The user has a much greater chance of finding/reading the issues article and its also likely to be written for a less technical user. The solution may occasionally involve modifying more than one file in the profile. For example, http://kb.mozillazine.org/Phantom_folders has the user delete several files in the profile.<br />
<br />
::::Looking at the articles in http://kb.mozillazine.org/Category:Preferences its clear a lot of effort was spent writing them and they have usefull information, but they're not focused on solving problems. IMHO they're really reference articles. I would expect the exact same thing to occur. If it does, then we need some way (a sentence in the rules?) to discourage an author of the file article from lobotomizing the issues article and adding a link to thier article to "avoid duplication". This problem may never occur, but I'd prefer we find some way to prevent it rather than deal with it later. [[User:Tanstaafl|Tanstaafl]] 23:27, 31 January 2006 (UTC)<br />
:::::Indeed, these would be reference articles. I don't really see much duplication. The issue article would describe a problem and say "...to fix it, delete [[downloads.rdf]] in your [[profile folder]]". The reference article would say X, Y, and Z about downloads.rdf, and possibly even incluse a link back to the issue article.--[[User:Np|Np]] 02:26, 1 February 2006 (UTC)<br />
<br />
::Copied from the [[Knowledge_Base_changes]] discussion under [[Knowledge_Base_changes#New_Proposal.E2.80.94Creating_an_article_for_each_profile_file. | New Proposal—Creating an article for each profile file]]:<br />
::''However, a seperate article for each file seems like overkill, and biased towards more technically knowledgeable users. I'd prefer to see the effort put into writing more issues articles instead. However, if the consensus is to write a seperate article for each file then each file in the profile article should be linked to the corresponding article. Tanstaafl 22:35, 31 January 2006 (UTC)''<br />
:::I tend to agree that creating a separate article about each file in the profile might be "overkill" and (if patterned after the "preferences" articles) probably biased towards the technically-oriented. I was thinking more along the lines of concentrating on the files in the profile that come up all the time on the support forums when I agreed with the proposal (like downloads.rdf, mimeTypes.rdf and localstore.rdf) and then linking the new articles and existing articles that mention the files with "See also" references. However, on the original proposal, as written above, ''We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--Np 18:25, 29 January 2006 (UTC)'' ... If the idea behind writing Profile "files" articles is to replace the [[Profile_folder#Files_and_folders_in_the_profile]] section with a category listing, same as the Preferences article category listings are replacing various sections of the [[About:config entries]] article, eventually you are going to get down to the files with very little useful information to the normal user, and those articles will be solely for reference purposes. As a practical matter, these last file articles could just be "stubs" so that effort isn't wasted in finding all sorts of technical details about files that no one really needs. [[User:Alice Wyman|Alice Wyman]] 16:35, 1 February 2006 (UTC)<br />
::::So the worst that could happen is "article no one needs". And the best that could happen is "article useful for the curious and technically-minded". Sounds fine to me. There's nothing wrong in including "reference" or "technical" information in the KB as long as it's not harmful towards less technically-oriented users. Being technically minded myself, I am interested in what random files in the profile do, so I'll contribute to documenting them, just like I do with the preference articles. It's not going to take away from me writing Issues articles because I don't know of any important enough issues to be documented that I haven't documented already. Plus it's my time to spend as I wish. Others who don't care about a certain file, as with anything else, don't need to contribute. --[[User:Np|Np]] 16:57, 1 February 2006 (UTC)<br />
:::::I think the point being made was, why waste time and effort on articles with limited usefulness when it could be better spent on articles that benefit more users, such as "issues" articles. The assumption is that the pool of available editors is limited. That's why I suggested "stub" articles at the point of diminishing returns. [[User:Alice Wyman|Alice Wyman]] 17:29, 1 February 2006 (UTC) <br />
::::::You're also assuming that editors would otherwise spend time on writing issues articles. That's not true. I, for one, don't have any potential Issues articles floating around in my brain that haven't been written yet. Also, there's no boss around here so maybe I'd rather go do some forum work or extension work or whatever than write an issues article. Anyway, I don't see these articles taking a lot of time to write, based on the brainstorming for possible information. The editors will certainly realize that some files you need to yak about and other files a brief description will do, so I don't see a need to formalize that point - just leave it at their discretion.--[[User:Np|Np]] 18:18, 1 February 2006 (UTC)<br />
::::::: I don't want to split hairs over who made what assumptions. I only brought up the idea of "stub" articles because you had proposed such a detailed list of what to include in "profile files" articles under [[Talk:Profile_folder#Information included (brainstorming)]]. No big deal. Anyway, instead of all this yakking someone should just go ahead and write that "downloads.rdf" or <''number''>.s" (passwords file) article and see what comes out. [[User:Alice Wyman|Alice Wyman]] 18:54, 1 February 2006 (UTC)<br />
:::::::: Yeah, I was going to give it a shot tonight.--[[User:Np|Np]] 18:58, 1 February 2006 (UTC)<br />
<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
::::I agree with Wintogreen. Firstly, I like the idea of adding the word "folder" to the end of article titles concerning subfolders of the profile folder. Secondly, I think that adding the folder path to the article title would be a bit of an overkill, as would creating mini-categories, ''unless'' filenames are not unique within the profile folder tree. In the latter case, we have no choice but to have some method of differentiation. (Ideally, we should keep things simple; "userChrome.css" has to be better than "chrome/userChrome.css". Incidentally, I'm not big on lumping userChrome and userContent together, although I can see the benefit of not needing to teach people CSS in two separate articles; what do others think?) --[[User:Mozcerize|Mozcerize]] 16:37, 30 January 2006 (UTC)<br />
:::::I'd suggest seperate articles that link to each other, and maybe to something like http://www.mozilla.org/unix/customizing.html . Let that external link take care of teaching CSS. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
<br />
What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --[[User:Wintogreen|wintogreen]] 16:36, 30 January 2006 (UTC)<br />
<br />
:You might use a generic phrase that has the word lock such as such as lock files. A quick search for articles with lock in the title currently only returns "lock icon". Think about the comparable problem for *.s , *.w, *.mab, *.msf, *.src files and the fast load (XUL) files. The latter has been called "XUL.mfl" , "XUL FastLoad File" and "XUL.mfasl". At one time there also were "Invalid.mfasl" and/or "Aborted.mfasl" invalidated fast load files. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
::Yeah, I guess that makes sense. We could insert a blurb at the top of the category page noting that some files will be listed alphabetically according to the filename extension/suffix or whatever. --[[User:Wintogreen|wintogreen]] 09:20, 2 February 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Its relationship to other files (ie whether it requires other files to work (like the password file), whether there are other places this info is stored, etc)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Whether it's feasible/advisable to manually edit it<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
::::The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. [[User:Tanstaafl|Tanstaafl]] 23:37, 31 January 2006 (UTC)<br />
:::::Why? I'd like to reiterate the point that I made elsewhere that, far from being confusing, the use of the wrongtitle template is ''essential'' in the case of these file articles where the capitalization is critical. Surely our first priority on the KB must be to keep things factually accurate. I think np's idea of creating a custom wrongtitle template for file articles is good; we can make it a little more accessible to non-technical users. --[[User:Mozcerize|Mozcerize]] 12:57, 2 February 2006 (UTC)<br />
<br />
===downloads.rdf as a test case===<br />
See [[downloads.rdf]] --[[User:Np|Np]] 23:42, 1 February 2006 (UTC)<br />
:I've added some TB info to the article, changed the last header from "Possible issues" to "Related issues", and bolded the filename in the first sentence to make it (and the correct capitalization) stand out. --[[User:Wintogreen|wintogreen]] 04:36, 2 February 2006 (UTC)<br />
<br />
Now that we've got this file as a kind of test case, a few comments/suggestions that could pertain to future articles:<br />
# Some of the files that are shared between apps (esp. between Firefox and Thunderbird) might serve rather different functions or be accessed through different UI. (mimeTypes.rdf and cookies.txt are a couple others.) In the downloads.rdf article, even the seemingly straightforward phrase "download history" can have a very different meaning in the context of email (think POP), and a statement like "downloads.rdf is the only place where download history is recorded" can easily be misunderstood as well. I'm not sure what the best way to deal with this in the present article, but it's something we should try to keep in mind when writing/editing these articles. (And for the record, I don't know how the Suite records attachment-saving operations. Do they go into downloads.rdf as they do with Thunderbird?)<br />
# The section about "Disabling": does it belong in this article? To my mind, it's essentially addressing a question about how to control the application behavior ("How can I stop Firefox from recording my downloads?"), and I thus think it should go into a regular article about managing download history, the Clear Private Data tool, or browser privacy. Even if there is no such regular article, it doesn't mean that the info should go into an existing "Profile file" article. More generally speaking, I think this relates to the concern Tanstaafl expressed earlier about the potential for these "Profile file" articles to the "lobotomize" the Issues [and other regular] articles.<br />
# In the same vein, I don't think these articles should be categorized together with the regular end-user articles (currently this one is in the "Privacy and security" category). As reference articles, they should be treated essentially like the Preferences articles. --[[User:Wintogreen|wintogreen]] 14:52, 2 February 2006 (UTC)<br />
<br />
===How these files will affect the profile folder article===<br />
To follow up on a previous comment by Alice, what's anyone thinking about how these articles will affect the present state of the [[profile folder]] article? Is the idea to simply linkify the filenames in the currently existing table? Personally, I hope so. I think it's fine the way the prefs listed in [[about:config entries]] are being removed from the list there once they're written up and put into [[:Category:Preferences]], since the pref titles themselves are generally descriptive enough to give you an idea of what the pref is for, but this isn't so true with the profile files. I like having the big list of files all on one page--each with very short description--so that you can scan through it quickly. --[[User:Wintogreen|wintogreen]] 15:07, 2 February 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)<br />
::I understand the logic of removing it, but it is hard to find usefull information and we don't have a good alternative place to tell somebody about it if they don't know the file exists. Perhaps we need an article describing the layout of the thunderbird program directory which identifies any usefull files (including ones you might need to tinker with if you have a problem), and then add it to "see also" in the profile article. [[User:Tanstaafl|Tanstaafl]] 22:22, 31 January 2006 (UTC)<br />
::: Sounds like a good idea. We could link to it in the [[Installation directory]] article as well. --[[User:Wintogreen|wintogreen]] 09:22, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22504Talk:Profile folder2006-02-02T14:52:40Z<p>Wintogreen: /* downloads.rdf as a test case */</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
:::: How do you propose avoiding duplication between a issues article and the corresponding files article? For example, suppose I wrote a thunderbird issue article on how to fix problems with opening an attachment with the desired utility by deleting mimetypes.rdf. The user has a much greater chance of finding/reading the issues article and its also likely to be written for a less technical user. The solution may occasionally involve modifying more than one file in the profile. For example, http://kb.mozillazine.org/Phantom_folders has the user delete several files in the profile.<br />
<br />
::::Looking at the articles in http://kb.mozillazine.org/Category:Preferences its clear a lot of effort was spent writing them and they have usefull information, but they're not focused on solving problems. IMHO they're really reference articles. I would expect the exact same thing to occur. If it does, then we need some way (a sentence in the rules?) to discourage an author of the file article from lobotomizing the issues article and adding a link to thier article to "avoid duplication". This problem may never occur, but I'd prefer we find some way to prevent it rather than deal with it later. [[User:Tanstaafl|Tanstaafl]] 23:27, 31 January 2006 (UTC)<br />
:::::Indeed, these would be reference articles. I don't really see much duplication. The issue article would describe a problem and say "...to fix it, delete [[downloads.rdf]] in your [[profile folder]]". The reference article would say X, Y, and Z about downloads.rdf, and possibly even incluse a link back to the issue article.--[[User:Np|Np]] 02:26, 1 February 2006 (UTC)<br />
<br />
::Copied from the [[Knowledge_Base_changes]] discussion under [[Knowledge_Base_changes#New_Proposal.E2.80.94Creating_an_article_for_each_profile_file. | New Proposal—Creating an article for each profile file]]:<br />
::''However, a seperate article for each file seems like overkill, and biased towards more technically knowledgeable users. I'd prefer to see the effort put into writing more issues articles instead. However, if the consensus is to write a seperate article for each file then each file in the profile article should be linked to the corresponding article. Tanstaafl 22:35, 31 January 2006 (UTC)''<br />
:::I tend to agree that creating a separate article about each file in the profile might be "overkill" and (if patterned after the "preferences" articles) probably biased towards the technically-oriented. I was thinking more along the lines of concentrating on the files in the profile that come up all the time on the support forums when I agreed with the proposal (like downloads.rdf, mimeTypes.rdf and localstore.rdf) and then linking the new articles and existing articles that mention the files with "See also" references. However, on the original proposal, as written above, ''We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--Np 18:25, 29 January 2006 (UTC)'' ... If the idea behind writing Profile "files" articles is to replace the [[Profile_folder#Files_and_folders_in_the_profile]] section with a category listing, same as the Preferences article category listings are replacing various sections of the [[About:config entries]] article, eventually you are going to get down to the files with very little useful information to the normal user, and those articles will be solely for reference purposes. As a practical matter, these last file articles could just be "stubs" so that effort isn't wasted in finding all sorts of technical details about files that no one really needs. [[User:Alice Wyman|Alice Wyman]] 16:35, 1 February 2006 (UTC)<br />
::::So the worst that could happen is "article no one needs". And the best that could happen is "article useful for the curious and technically-minded". Sounds fine to me. There's nothing wrong in including "reference" or "technical" information in the KB as long as it's not harmful towards less technically-oriented users. Being technically minded myself, I am interested in what random files in the profile do, so I'll contribute to documenting them, just like I do with the preference articles. It's not going to take away from me writing Issues articles because I don't know of any important enough issues to be documented that I haven't documented already. Plus it's my time to spend as I wish. Others who don't care about a certain file, as with anything else, don't need to contribute. --[[User:Np|Np]] 16:57, 1 February 2006 (UTC)<br />
:::::I think the point being made was, why waste time and effort on articles with limited usefulness when it could be better spent on articles that benefit more users, such as "issues" articles. The assumption is that the pool of available editors is limited. That's why I suggested "stub" articles at the point of diminishing returns. [[User:Alice Wyman|Alice Wyman]] 17:29, 1 February 2006 (UTC) <br />
::::::You're also assuming that editors would otherwise spend time on writing issues articles. That's not true. I, for one, don't have any potential Issues articles floating around in my brain that haven't been written yet. Also, there's no boss around here so maybe I'd rather go do some forum work or extension work or whatever than write an issues article. Anyway, I don't see these articles taking a lot of time to write, based on the brainstorming for possible information. The editors will certainly realize that some files you need to yak about and other files a brief description will do, so I don't see a need to formalize that point - just leave it at their discretion.--[[User:Np|Np]] 18:18, 1 February 2006 (UTC)<br />
::::::: I don't want to split hairs over who made what assumptions. I only brought up the idea of "stub" articles because you had proposed such a detailed list of what to include in "profile files" articles under [[Talk:Profile_folder#Information included (brainstorming)]]. No big deal. Anyway, instead of all this yakking someone should just go ahead and write that "downloads.rdf" or <''number''>.s" (passwords file) article and see what comes out. [[User:Alice Wyman|Alice Wyman]] 18:54, 1 February 2006 (UTC)<br />
:::::::: Yeah, I was going to give it a shot tonight.--[[User:Np|Np]] 18:58, 1 February 2006 (UTC)<br />
<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
::::I agree with Wintogreen. Firstly, I like the idea of adding the word "folder" to the end of article titles concerning subfolders of the profile folder. Secondly, I think that adding the folder path to the article title would be a bit of an overkill, as would creating mini-categories, ''unless'' filenames are not unique within the profile folder tree. In the latter case, we have no choice but to have some method of differentiation. (Ideally, we should keep things simple; "userChrome.css" has to be better than "chrome/userChrome.css". Incidentally, I'm not big on lumping userChrome and userContent together, although I can see the benefit of not needing to teach people CSS in two separate articles; what do others think?) --[[User:Mozcerize|Mozcerize]] 16:37, 30 January 2006 (UTC)<br />
:::::I'd suggest seperate articles that link to each other, and maybe to something like http://www.mozilla.org/unix/customizing.html . Let that external link take care of teaching CSS. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
<br />
What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --[[User:Wintogreen|wintogreen]] 16:36, 30 January 2006 (UTC)<br />
<br />
:You might use a generic phrase that has the word lock such as such as lock files. A quick search for articles with lock in the title currently only returns "lock icon". Think about the comparable problem for *.s , *.w, *.mab, *.msf, *.src files and the fast load (XUL) files. The latter has been called "XUL.mfl" , "XUL FastLoad File" and "XUL.mfasl". At one time there also were "Invalid.mfasl" and/or "Aborted.mfasl" invalidated fast load files. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
::Yeah, I guess that makes sense. We could insert a blurb at the top of the category page noting that some files will be listed alphabetically according to the filename extension/suffix or whatever. --[[User:Wintogreen|wintogreen]] 09:20, 2 February 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Its relationship to other files (ie whether it requires other files to work (like the password file), whether there are other places this info is stored, etc)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Whether it's feasible/advisable to manually edit it<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
::::The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. [[User:Tanstaafl|Tanstaafl]] 23:37, 31 January 2006 (UTC)<br />
:::::Why? I'd like to reiterate the point that I made elsewhere that, far from being confusing, the use of the wrongtitle template is ''essential'' in the case of these file articles where the capitalization is critical. Surely our first priority on the KB must be to keep things factually accurate. I think np's idea of creating a custom wrongtitle template for file articles is good; we can make it a little more accessible to non-technical users. --[[User:Mozcerize|Mozcerize]] 12:57, 2 February 2006 (UTC)<br />
<br />
===downloads.rdf as a test case===<br />
See [[downloads.rdf]] --[[User:Np|Np]] 23:42, 1 February 2006 (UTC)<br />
:I've added some TB info to the article, changed the last header from "Possible issues" to "Related issues", and bolded the filename in the first sentence to make it (and the correct capitalization) stand out. --[[User:Wintogreen|wintogreen]] 04:36, 2 February 2006 (UTC)<br />
<br />
Now that we've got this file as a kind of test case, a few comments/suggestions that could pertain to future articles:<br />
# Some of the files that are shared between apps (esp. between Firefox and Thunderbird) might serve rather different functions or be accessed through different UI. (mimeTypes.rdf and cookies.txt are a couple others.) In the downloads.rdf article, even the seemingly straightforward phrase "download history" can have a very different meaning in the context of email (think POP), and a statement like "downloads.rdf is the only place where download history is recorded" can easily be misunderstood as well. I'm not sure what the best way to deal with this in the present article, but it's something we should try to keep in mind when writing/editing these articles. (And for the record, I don't know how the Suite records attachment-saving operations. Do they go into downloads.rdf as they do with Thunderbird?)<br />
# The section about "Disabling": does it belong in this article? To my mind, it's essentially addressing a question about how to control the application behavior ("How can I stop Firefox from recording my downloads?"), and I thus think it should go into a regular article about managing download history, the Clear Private Data tool, or browser privacy. Even if there is no such regular article, it doesn't mean that the info should go into an existing "Profile file" article. More generally speaking, I think this relates to the concern Tanstaafl expressed earlier about the potential for these "Profile file" articles to the "lobotomize" the Issues [and other regular] articles.<br />
# In the same vein, I don't think these articles should be categorized together with the regular end-user articles (currently this one is in the "Privacy and security" category). As reference articles, they should be treated essentially like the Preferences articles. --[[User:Wintogreen|wintogreen]] 14:52, 2 February 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)<br />
::I understand the logic of removing it, but it is hard to find usefull information and we don't have a good alternative place to tell somebody about it if they don't know the file exists. Perhaps we need an article describing the layout of the thunderbird program directory which identifies any usefull files (including ones you might need to tinker with if you have a problem), and then add it to "see also" in the profile article. [[User:Tanstaafl|Tanstaafl]] 22:22, 31 January 2006 (UTC)<br />
::: Sounds like a good idea. We could link to it in the [[Installation directory]] article as well. --[[User:Wintogreen|wintogreen]] 09:22, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22487Talk:Profile folder2006-02-02T09:22:44Z<p>Wintogreen: /* Files outside the "Profiles" folder */</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
:::: How do you propose avoiding duplication between a issues article and the corresponding files article? For example, suppose I wrote a thunderbird issue article on how to fix problems with opening an attachment with the desired utility by deleting mimetypes.rdf. The user has a much greater chance of finding/reading the issues article and its also likely to be written for a less technical user. The solution may occasionally involve modifying more than one file in the profile. For example, http://kb.mozillazine.org/Phantom_folders has the user delete several files in the profile.<br />
<br />
::::Looking at the articles in http://kb.mozillazine.org/Category:Preferences its clear a lot of effort was spent writing them and they have usefull information, but they're not focused on solving problems. IMHO they're really reference articles. I would expect the exact same thing to occur. If it does, then we need some way (a sentence in the rules?) to discourage an author of the file article from lobotomizing the issues article and adding a link to thier article to "avoid duplication". This problem may never occur, but I'd prefer we find some way to prevent it rather than deal with it later. [[User:Tanstaafl|Tanstaafl]] 23:27, 31 January 2006 (UTC)<br />
:::::Indeed, these would be reference articles. I don't really see much duplication. The issue article would describe a problem and say "...to fix it, delete [[downloads.rdf]] in your [[profile folder]]". The reference article would say X, Y, and Z about downloads.rdf, and possibly even incluse a link back to the issue article.--[[User:Np|Np]] 02:26, 1 February 2006 (UTC)<br />
<br />
::Copied from the [[Knowledge_Base_changes]] discussion under [[Knowledge_Base_changes#New_Proposal.E2.80.94Creating_an_article_for_each_profile_file. | New Proposal—Creating an article for each profile file]]:<br />
::''However, a seperate article for each file seems like overkill, and biased towards more technically knowledgeable users. I'd prefer to see the effort put into writing more issues articles instead. However, if the consensus is to write a seperate article for each file then each file in the profile article should be linked to the corresponding article. Tanstaafl 22:35, 31 January 2006 (UTC)''<br />
:::I tend to agree that creating a separate article about each file in the profile might be "overkill" and (if patterned after the "preferences" articles) probably biased towards the technically-oriented. I was thinking more along the lines of concentrating on the files in the profile that come up all the time on the support forums when I agreed with the proposal (like downloads.rdf, mimeTypes.rdf and localstore.rdf) and then linking the new articles and existing articles that mention the files with "See also" references. However, on the original proposal, as written above, ''We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--Np 18:25, 29 January 2006 (UTC)'' ... If the idea behind writing Profile "files" articles is to replace the [[Profile_folder#Files_and_folders_in_the_profile]] section with a category listing, same as the Preferences article category listings are replacing various sections of the [[About:config entries]] article, eventually you are going to get down to the files with very little useful information to the normal user, and those articles will be solely for reference purposes. As a practical matter, these last file articles could just be "stubs" so that effort isn't wasted in finding all sorts of technical details about files that no one really needs. [[User:Alice Wyman|Alice Wyman]] 16:35, 1 February 2006 (UTC)<br />
::::So the worst that could happen is "article no one needs". And the best that could happen is "article useful for the curious and technically-minded". Sounds fine to me. There's nothing wrong in including "reference" or "technical" information in the KB as long as it's not harmful towards less technically-oriented users. Being technically minded myself, I am interested in what random files in the profile do, so I'll contribute to documenting them, just like I do with the preference articles. It's not going to take away from me writing Issues articles because I don't know of any important enough issues to be documented that I haven't documented already. Plus it's my time to spend as I wish. Others who don't care about a certain file, as with anything else, don't need to contribute. --[[User:Np|Np]] 16:57, 1 February 2006 (UTC)<br />
:::::I think the point being made was, why waste time and effort on articles with limited usefulness when it could be better spent on articles that benefit more users, such as "issues" articles. The assumption is that the pool of available editors is limited. That's why I suggested "stub" articles at the point of diminishing returns. [[User:Alice Wyman|Alice Wyman]] 17:29, 1 February 2006 (UTC) <br />
::::::You're also assuming that editors would otherwise spend time on writing issues articles. That's not true. I, for one, don't have any potential Issues articles floating around in my brain that haven't been written yet. Also, there's no boss around here so maybe I'd rather go do some forum work or extension work or whatever than write an issues article. Anyway, I don't see these articles taking a lot of time to write, based on the brainstorming for possible information. The editors will certainly realize that some files you need to yak about and other files a brief description will do, so I don't see a need to formalize that point - just leave it at their discretion.--[[User:Np|Np]] 18:18, 1 February 2006 (UTC)<br />
::::::: I don't want to split hairs over who made what assumptions. I only brought up the idea of "stub" articles because you had proposed such a detailed list of what to include in "profile files" articles under [[Talk:Profile_folder#Information included (brainstorming)]]. No big deal. Anyway, instead of all this yakking someone should just go ahead and write that "downloads.rdf" or <''number''>.s" (passwords file) article and see what comes out. [[User:Alice Wyman|Alice Wyman]] 18:54, 1 February 2006 (UTC)<br />
:::::::: Yeah, I was going to give it a shot tonight.--[[User:Np|Np]] 18:58, 1 February 2006 (UTC)<br />
<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
::::I agree with Wintogreen. Firstly, I like the idea of adding the word "folder" to the end of article titles concerning subfolders of the profile folder. Secondly, I think that adding the folder path to the article title would be a bit of an overkill, as would creating mini-categories, ''unless'' filenames are not unique within the profile folder tree. In the latter case, we have no choice but to have some method of differentiation. (Ideally, we should keep things simple; "userChrome.css" has to be better than "chrome/userChrome.css". Incidentally, I'm not big on lumping userChrome and userContent together, although I can see the benefit of not needing to teach people CSS in two separate articles; what do others think?) --[[User:Mozcerize|Mozcerize]] 16:37, 30 January 2006 (UTC)<br />
:::::I'd suggest seperate articles that link to each other, and maybe to something like http://www.mozilla.org/unix/customizing.html . Let that external link take care of teaching CSS. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
<br />
What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --[[User:Wintogreen|wintogreen]] 16:36, 30 January 2006 (UTC)<br />
<br />
:You might use a generic phrase that has the word lock such as such as lock files. A quick search for articles with lock in the title currently only returns "lock icon". Think about the comparable problem for *.s , *.w, *.mab, *.msf, *.src files and the fast load (XUL) files. The latter has been called "XUL.mfl" , "XUL FastLoad File" and "XUL.mfasl". At one time there also were "Invalid.mfasl" and/or "Aborted.mfasl" invalidated fast load files. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
::Yeah, I guess that makes sense. We could insert a blurb at the top of the category page noting that some files will be listed alphabetically according to the filename extension/suffix or whatever. --[[User:Wintogreen|wintogreen]] 09:20, 2 February 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Its relationship to other files (ie whether it requires other files to work (like the password file), whether there are other places this info is stored, etc)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Whether it's feasible/advisable to manually edit it<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
::::The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. [[User:Tanstaafl|Tanstaafl]] 23:37, 31 January 2006 (UTC)<br />
See [[downloads.rdf]] --[[User:Np|Np]] 23:42, 1 February 2006 (UTC)<br />
:I've added some TB info to the article, changed the last header from "Possible issues" to "Related issues", and bolded the filename in the first sentence to make it (and the correct capitalization) stand out. --[[User:Wintogreen|wintogreen]] 04:36, 2 February 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)<br />
::I understand the logic of removing it, but it is hard to find usefull information and we don't have a good alternative place to tell somebody about it if they don't know the file exists. Perhaps we need an article describing the layout of the thunderbird program directory which identifies any usefull files (including ones you might need to tinker with if you have a problem), and then add it to "see also" in the profile article. [[User:Tanstaafl|Tanstaafl]] 22:22, 31 January 2006 (UTC)<br />
::: Sounds like a good idea. We could link to it in the [[Installation directory]] article as well. --[[User:Wintogreen|wintogreen]] 09:22, 2 February 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22486Talk:Profile folder2006-02-02T09:20:48Z<p>Wintogreen: /* Proposed hierarchy */ files with diff. names by OS or no fixed name</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
:::: How do you propose avoiding duplication between a issues article and the corresponding files article? For example, suppose I wrote a thunderbird issue article on how to fix problems with opening an attachment with the desired utility by deleting mimetypes.rdf. The user has a much greater chance of finding/reading the issues article and its also likely to be written for a less technical user. The solution may occasionally involve modifying more than one file in the profile. For example, http://kb.mozillazine.org/Phantom_folders has the user delete several files in the profile.<br />
<br />
::::Looking at the articles in http://kb.mozillazine.org/Category:Preferences its clear a lot of effort was spent writing them and they have usefull information, but they're not focused on solving problems. IMHO they're really reference articles. I would expect the exact same thing to occur. If it does, then we need some way (a sentence in the rules?) to discourage an author of the file article from lobotomizing the issues article and adding a link to thier article to "avoid duplication". This problem may never occur, but I'd prefer we find some way to prevent it rather than deal with it later. [[User:Tanstaafl|Tanstaafl]] 23:27, 31 January 2006 (UTC)<br />
:::::Indeed, these would be reference articles. I don't really see much duplication. The issue article would describe a problem and say "...to fix it, delete [[downloads.rdf]] in your [[profile folder]]". The reference article would say X, Y, and Z about downloads.rdf, and possibly even incluse a link back to the issue article.--[[User:Np|Np]] 02:26, 1 February 2006 (UTC)<br />
<br />
::Copied from the [[Knowledge_Base_changes]] discussion under [[Knowledge_Base_changes#New_Proposal.E2.80.94Creating_an_article_for_each_profile_file. | New Proposal—Creating an article for each profile file]]:<br />
::''However, a seperate article for each file seems like overkill, and biased towards more technically knowledgeable users. I'd prefer to see the effort put into writing more issues articles instead. However, if the consensus is to write a seperate article for each file then each file in the profile article should be linked to the corresponding article. Tanstaafl 22:35, 31 January 2006 (UTC)''<br />
:::I tend to agree that creating a separate article about each file in the profile might be "overkill" and (if patterned after the "preferences" articles) probably biased towards the technically-oriented. I was thinking more along the lines of concentrating on the files in the profile that come up all the time on the support forums when I agreed with the proposal (like downloads.rdf, mimeTypes.rdf and localstore.rdf) and then linking the new articles and existing articles that mention the files with "See also" references. However, on the original proposal, as written above, ''We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--Np 18:25, 29 January 2006 (UTC)'' ... If the idea behind writing Profile "files" articles is to replace the [[Profile_folder#Files_and_folders_in_the_profile]] section with a category listing, same as the Preferences article category listings are replacing various sections of the [[About:config entries]] article, eventually you are going to get down to the files with very little useful information to the normal user, and those articles will be solely for reference purposes. As a practical matter, these last file articles could just be "stubs" so that effort isn't wasted in finding all sorts of technical details about files that no one really needs. [[User:Alice Wyman|Alice Wyman]] 16:35, 1 February 2006 (UTC)<br />
::::So the worst that could happen is "article no one needs". And the best that could happen is "article useful for the curious and technically-minded". Sounds fine to me. There's nothing wrong in including "reference" or "technical" information in the KB as long as it's not harmful towards less technically-oriented users. Being technically minded myself, I am interested in what random files in the profile do, so I'll contribute to documenting them, just like I do with the preference articles. It's not going to take away from me writing Issues articles because I don't know of any important enough issues to be documented that I haven't documented already. Plus it's my time to spend as I wish. Others who don't care about a certain file, as with anything else, don't need to contribute. --[[User:Np|Np]] 16:57, 1 February 2006 (UTC)<br />
:::::I think the point being made was, why waste time and effort on articles with limited usefulness when it could be better spent on articles that benefit more users, such as "issues" articles. The assumption is that the pool of available editors is limited. That's why I suggested "stub" articles at the point of diminishing returns. [[User:Alice Wyman|Alice Wyman]] 17:29, 1 February 2006 (UTC) <br />
::::::You're also assuming that editors would otherwise spend time on writing issues articles. That's not true. I, for one, don't have any potential Issues articles floating around in my brain that haven't been written yet. Also, there's no boss around here so maybe I'd rather go do some forum work or extension work or whatever than write an issues article. Anyway, I don't see these articles taking a lot of time to write, based on the brainstorming for possible information. The editors will certainly realize that some files you need to yak about and other files a brief description will do, so I don't see a need to formalize that point - just leave it at their discretion.--[[User:Np|Np]] 18:18, 1 February 2006 (UTC)<br />
::::::: I don't want to split hairs over who made what assumptions. I only brought up the idea of "stub" articles because you had proposed such a detailed list of what to include in "profile files" articles under [[Talk:Profile_folder#Information included (brainstorming)]]. No big deal. Anyway, instead of all this yakking someone should just go ahead and write that "downloads.rdf" or <''number''>.s" (passwords file) article and see what comes out. [[User:Alice Wyman|Alice Wyman]] 18:54, 1 February 2006 (UTC)<br />
:::::::: Yeah, I was going to give it a shot tonight.--[[User:Np|Np]] 18:58, 1 February 2006 (UTC)<br />
<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
::::I agree with Wintogreen. Firstly, I like the idea of adding the word "folder" to the end of article titles concerning subfolders of the profile folder. Secondly, I think that adding the folder path to the article title would be a bit of an overkill, as would creating mini-categories, ''unless'' filenames are not unique within the profile folder tree. In the latter case, we have no choice but to have some method of differentiation. (Ideally, we should keep things simple; "userChrome.css" has to be better than "chrome/userChrome.css". Incidentally, I'm not big on lumping userChrome and userContent together, although I can see the benefit of not needing to teach people CSS in two separate articles; what do others think?) --[[User:Mozcerize|Mozcerize]] 16:37, 30 January 2006 (UTC)<br />
:::::I'd suggest seperate articles that link to each other, and maybe to something like http://www.mozilla.org/unix/customizing.html . Let that external link take care of teaching CSS. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
<br />
What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --[[User:Wintogreen|wintogreen]] 16:36, 30 January 2006 (UTC)<br />
<br />
:You might use a generic phrase that has the word lock such as such as lock files. A quick search for articles with lock in the title currently only returns "lock icon". Think about the comparable problem for *.s , *.w, *.mab, *.msf, *.src files and the fast load (XUL) files. The latter has been called "XUL.mfl" , "XUL FastLoad File" and "XUL.mfasl". At one time there also were "Invalid.mfasl" and/or "Aborted.mfasl" invalidated fast load files. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
::Yeah, I guess that makes sense. We could insert a blurb at the top of the category page noting that some files will be listed alphabetically according to the filename extension/suffix or whatever. --[[User:Wintogreen|wintogreen]] 09:20, 2 February 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Its relationship to other files (ie whether it requires other files to work (like the password file), whether there are other places this info is stored, etc)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Whether it's feasible/advisable to manually edit it<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
::::The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. [[User:Tanstaafl|Tanstaafl]] 23:37, 31 January 2006 (UTC)<br />
See [[downloads.rdf]] --[[User:Np|Np]] 23:42, 1 February 2006 (UTC)<br />
:I've added some TB info to the article, changed the last header from "Possible issues" to "Related issues", and bolded the filename in the first sentence to make it (and the correct capitalization) stand out. --[[User:Wintogreen|wintogreen]] 04:36, 2 February 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)<br />
::I understand the logic of removing it, but it is hard to find usefull information and we don't have a good alternative place to tell somebody about it if they don't know the file exists. Perhaps we need an article describing the layout of the thunderbird program directory which identifies any usefull files (including ones you might need to tinker with if you have a problem), and then add it to "see also" in the profile article. [[User:Tanstaafl|Tanstaafl]] 22:22, 31 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Attachment_save_slow_-_Thunderbird&diff=22484Attachment save slow - Thunderbird2006-02-02T05:22:19Z<p>Wintogreen: /* External links */ adding bug link</p>
<hr />
<div>== Symptoms ==<br />
<br />
In Windows, when trying to save an e-mail attachment, Thunderbird appears to hang for 10-45 seconds. It may appear that Thunderbird won't recover, but if you wait long enough, you are presented with a dialog box that lets you choose where to save the file (or the file is saved, if your Thunderbird preferences are set to always save to a specific location.)<br />
<br />
== Solution ==<br />
<br />
This can be caused by a bloated "downloads.rdf" file in your Thunderbird [[profile folder]]. Try the following.<br />
# Exit Thunderbird if it is running.<br />
# Recommended: make a temporary [[profile backup|backup]] of your Thunderbird profile folder (or at least of the downloads.rdf file).<br />
# Delete the downloads.rdf file from your profile folder.<br />
<br />
== External links == <br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=239136 Bug 239136]: Thunderbird needs to integrate with the new download manager (fixed as of [http://forums.mozillazine.org/viewtopic.php?t=374949 2006-02-01 trunk builds])<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=320744 Bug 320744: no way to clear downloads.rdf] (fixed as part of Bug 239136)<br />
* [http://forums.mozillazine.org/viewtopic.php?t=310704 Forum article dealing with this issue]<br />
<br />
[[Category:Issues (Thunderbird)]]<br />
[[Category:Attachments (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22483Talk:Profile folder2006-02-02T04:36:20Z<p>Wintogreen: /* Information included (brainstorming) */</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
:::: How do you propose avoiding duplication between a issues article and the corresponding files article? For example, suppose I wrote a thunderbird issue article on how to fix problems with opening an attachment with the desired utility by deleting mimetypes.rdf. The user has a much greater chance of finding/reading the issues article and its also likely to be written for a less technical user. The solution may occasionally involve modifying more than one file in the profile. For example, http://kb.mozillazine.org/Phantom_folders has the user delete several files in the profile.<br />
<br />
::::Looking at the articles in http://kb.mozillazine.org/Category:Preferences its clear a lot of effort was spent writing them and they have usefull information, but they're not focused on solving problems. IMHO they're really reference articles. I would expect the exact same thing to occur. If it does, then we need some way (a sentence in the rules?) to discourage an author of the file article from lobotomizing the issues article and adding a link to thier article to "avoid duplication". This problem may never occur, but I'd prefer we find some way to prevent it rather than deal with it later. [[User:Tanstaafl|Tanstaafl]] 23:27, 31 January 2006 (UTC)<br />
:::::Indeed, these would be reference articles. I don't really see much duplication. The issue article would describe a problem and say "...to fix it, delete [[downloads.rdf]] in your [[profile folder]]". The reference article would say X, Y, and Z about downloads.rdf, and possibly even incluse a link back to the issue article.--[[User:Np|Np]] 02:26, 1 February 2006 (UTC)<br />
<br />
::Copied from the [[Knowledge_Base_changes]] discussion under [[Knowledge_Base_changes#New_Proposal.E2.80.94Creating_an_article_for_each_profile_file. | New Proposal—Creating an article for each profile file]]:<br />
::''However, a seperate article for each file seems like overkill, and biased towards more technically knowledgeable users. I'd prefer to see the effort put into writing more issues articles instead. However, if the consensus is to write a seperate article for each file then each file in the profile article should be linked to the corresponding article. Tanstaafl 22:35, 31 January 2006 (UTC)''<br />
:::I tend to agree that creating a separate article about each file in the profile might be "overkill" and (if patterned after the "preferences" articles) probably biased towards the technically-oriented. I was thinking more along the lines of concentrating on the files in the profile that come up all the time on the support forums when I agreed with the proposal (like downloads.rdf, mimeTypes.rdf and localstore.rdf) and then linking the new articles and existing articles that mention the files with "See also" references. However, on the original proposal, as written above, ''We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--Np 18:25, 29 January 2006 (UTC)'' ... If the idea behind writing Profile "files" articles is to replace the [[Profile_folder#Files_and_folders_in_the_profile]] section with a category listing, same as the Preferences article category listings are replacing various sections of the [[About:config entries]] article, eventually you are going to get down to the files with very little useful information to the normal user, and those articles will be solely for reference purposes. As a practical matter, these last file articles could just be "stubs" so that effort isn't wasted in finding all sorts of technical details about files that no one really needs. [[User:Alice Wyman|Alice Wyman]] 16:35, 1 February 2006 (UTC)<br />
::::So the worst that could happen is "article no one needs". And the best that could happen is "article useful for the curious and technically-minded". Sounds fine to me. There's nothing wrong in including "reference" or "technical" information in the KB as long as it's not harmful towards less technically-oriented users. Being technically minded myself, I am interested in what random files in the profile do, so I'll contribute to documenting them, just like I do with the preference articles. It's not going to take away from me writing Issues articles because I don't know of any important enough issues to be documented that I haven't documented already. Plus it's my time to spend as I wish. Others who don't care about a certain file, as with anything else, don't need to contribute. --[[User:Np|Np]] 16:57, 1 February 2006 (UTC)<br />
:::::I think the point being made was, why waste time and effort on articles with limited usefulness when it could be better spent on articles that benefit more users, such as "issues" articles. The assumption is that the pool of available editors is limited. That's why I suggested "stub" articles at the point of diminishing returns. [[User:Alice Wyman|Alice Wyman]] 17:29, 1 February 2006 (UTC) <br />
::::::You're also assuming that editors would otherwise spend time on writing issues articles. That's not true. I, for one, don't have any potential Issues articles floating around in my brain that haven't been written yet. Also, there's no boss around here so maybe I'd rather go do some forum work or extension work or whatever than write an issues article. Anyway, I don't see these articles taking a lot of time to write, based on the brainstorming for possible information. The editors will certainly realize that some files you need to yak about and other files a brief description will do, so I don't see a need to formalize that point - just leave it at their discretion.--[[User:Np|Np]] 18:18, 1 February 2006 (UTC)<br />
::::::: I don't want to split hairs over who made what assumptions. I only brought up the idea of "stub" articles because you had proposed such a detailed list of what to include in "profile files" articles under [[Talk:Profile_folder#Information included (brainstorming)]]. No big deal. Anyway, instead of all this yakking someone should just go ahead and write that "downloads.rdf" or <''number''>.s" (passwords file) article and see what comes out. [[User:Alice Wyman|Alice Wyman]] 18:54, 1 February 2006 (UTC)<br />
:::::::: Yeah, I was going to give it a shot tonight.--[[User:Np|Np]] 18:58, 1 February 2006 (UTC)<br />
<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome folder<br />
|-userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
::::I agree with Wintogreen. Firstly, I like the idea of adding the word "folder" to the end of article titles concerning subfolders of the profile folder. Secondly, I think that adding the folder path to the article title would be a bit of an overkill, as would creating mini-categories, ''unless'' filenames are not unique within the profile folder tree. In the latter case, we have no choice but to have some method of differentiation. (Ideally, we should keep things simple; "userChrome.css" has to be better than "chrome/userChrome.css". Incidentally, I'm not big on lumping userChrome and userContent together, although I can see the benefit of not needing to teach people CSS in two separate articles; what do others think?) --[[User:Mozcerize|Mozcerize]] 16:37, 30 January 2006 (UTC)<br />
:::::I'd suggest seperate articles that link to each other, and maybe to something like http://www.mozilla.org/unix/customizing.html . Let that external link take care of teaching CSS. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
<br />
What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --[[User:Wintogreen|wintogreen]] 16:36, 30 January 2006 (UTC)<br />
<br />
:You might use a generic phrase that has the word lock such as such as lock files. A quick search for articles with lock in the title currently only returns "lock icon". Think about the comparable problem for *.s , *.w, *.mab, *.msf, *.src files and the fast load (XUL) files. The latter has been called "XUL.mfl" , "XUL FastLoad File" and "XUL.mfasl". At one time there also were "Invalid.mfasl" and/or "Aborted.mfasl" invalidated fast load files. [[User:Tanstaafl|Tanstaafl]] 00:33, 2 February 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Its relationship to other files (ie whether it requires other files to work (like the password file), whether there are other places this info is stored, etc)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Whether it's feasible/advisable to manually edit it<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
::::The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. [[User:Tanstaafl|Tanstaafl]] 23:37, 31 January 2006 (UTC)<br />
See [[downloads.rdf]] --[[User:Np|Np]] 23:42, 1 February 2006 (UTC)<br />
:I've added some TB info to the article, changed the last header from "Possible issues" to "Related issues", and bolded the filename in the first sentence to make it (and the correct capitalization) stand out. --[[User:Wintogreen|wintogreen]] 04:36, 2 February 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)<br />
::I understand the logic of removing it, but it is hard to find usefull information and we don't have a good alternative place to tell somebody about it if they don't know the file exists. Perhaps we need an article describing the layout of the thunderbird program directory which identifies any usefull files (including ones you might need to tinker with if you have a problem), and then add it to "see also" in the profile article. [[User:Tanstaafl|Tanstaafl]] 22:22, 31 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Downloads.rdf&diff=22482Downloads.rdf2006-02-02T04:27:17Z<p>Wintogreen: added TB info, bolded filename, changed last header to "Related issues"</p>
<hr />
<div>''(This is an example of a profile file article. See [[Talk:Profile folder]] for discussion.)''<br />
<br />
'''downloads.rdf''' is a file in the [[profile folder]]. In Firefox and Mozilla Suite, it contains download history, and its contents can be viewed and managed through the [[Download Manager]]. In Thunderbird, it contains a history of attachments opened or saved by double-clicking on files listed in the Attachments pane or by using the menu sequence "File -> Attachments -> [attachment name] -> Open". Thunderbird has no UI for viewing or managing the contents of this file.<br />
<br />
==Editing==<br />
It's not advisable to edit this file manually because of its complexity and the fact that, in Firefox and Mozilla Suite, the Download Manager provides an interface to edit it.<br />
<br />
==Moving==<br />
This file can be moved to a different profile without any extra effort.<br />
<br />
==Deleting==<br />
Deleting downloads.rdf will clear your downloads history. A new file will be created on start up or when the application first needs to write to the file.<br />
<br />
==Related issues==<br />
* [[Firefox hangs]]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=159107 Bug 159107 - page saving/downloads takes too much time (is slow) ('marooned' entries in downloads.rdf)]<br />
* [[Attachment save slow (Thunderbird)]] (also see bug link in article)<br />
<br />
[[Category:Profile contents (Firefox)]]<br />
[[Category:Profile contents (Thunderbird)]]<br />
[[Category:Profile contents (Mozilla Suite)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Gylfi&diff=22430Talk:Gylfi2006-01-31T04:53:59Z<p>Wintogreen: Talk:Gylfi moved to Talk:Message Grouping: vandalism</p>
<hr />
<div>#redirect [[Talk:Message Grouping]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Message_Grouping&diff=22429Talk:Message Grouping2006-01-31T04:53:59Z<p>Wintogreen: Talk:Gylfi moved to Talk:Message Grouping</p>
<hr />
<div>Simply typing G does not work (on Win XP Pro sp2). Version 1.0<br />
<br />
== Message will not thread at all unless the 'view all messages selected' ==<br />
<br />
Why? I wish to thread messages in a newsgroup by subject, but it's not possible unless I select 'view all' messages. In a group with thousands of messages.....<br />
<br />
jak<br />
<br />
== Nested Sort ==<br />
<br />
The sort function needs to allow for a nested sort. For example, if I have all my messages go to the global inbox, and then want to sort/group them by email account (recipient), it would be nice to further sort the messages by date (ascending or decending). Is there already a way to do this and I am just missing it?<br />
<br />
How about a "Group By" funtion in addition to the "Sort By" funtion?<br />
<br />
jbh</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Gylfi&diff=22428Gylfi2006-01-31T04:53:59Z<p>Wintogreen: Gylfi moved to Message Grouping: vandalism</p>
<hr />
<div>#redirect [[Message Grouping]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Message_Grouping&diff=22427Message Grouping2006-01-31T04:53:59Z<p>Wintogreen: Gylfi moved to Message Grouping</p>
<hr />
<div>Beginning with Thunderbird version 0.9, the '''Message Grouping''' (Group by Sort) feature lets you organize messages in the message list into self-contained groups according to attributes such as date, sender or priority. For instance, if you set your Inbox to group messages by date, the messages will be organized into folder-like groups labelled Today, Yesterday, Last Week, and so on. You can expand or collapse each group by clicking on the small +/- mark next to the group label. ([http://www.mozilla.org/projects/thunderbird/specs/images/MessageGrouping.png screenshot])<br />
<br />
Messages can be grouped according to date, priority, sender, recipient, status, subject, or label.<br />
*''To group messages:'' first click on the folder that you want to use (such as your Inbox) and sort the messages in your preferred way: either click on a column heading such as "Date" in the message-list pane, or make a selection from "View -> Sort by". Then select "View -> Sort by -> Grouped By Sort" or simply press the letter "G" on your keyboard.<br />
*''To turn off message grouping:'' click on any column heading in the message-list pane or choose a different sort order from "View -> Sort by".<br />
<br />
===Other information===<br />
* Message grouping works on a per-folder basis. For example, message grouping that you apply to the Inbox folder will not be applied to the Sent folder or any other folders.<br />
* Message grouping does not currently work with [[Saved Search]] folders.<br />
* It's possible to [[Message Grouping header font | customize the font and background colors]] used for the header rows (e.g., "Today", "Yesterday", etc.).<br />
<br />
[[Category:Organizing and finding messages (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Help:Contents&diff=22411Help:Contents2006-01-30T19:05:19Z<p>Wintogreen: spam off</p>
<hr />
<div>#REDIRECT [[MozillaZine Knowledge Base:About]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=In-house_style&diff=22410In-house style2006-01-30T19:02:36Z<p>Wintogreen: opening paragraph</p>
<hr />
<div>{{org}}<br />
This page explains the style guidelines that we try to follow when editing articles to help keep the Knowledge Base looking consistent and professional. If you're a newcomer to the Knowledge Base, don't feel that you need to master everything listed below before you can create a new article or contribute to an existing one. The most important thing is for you to add your contribution to the Knowledge Base; someone else can tidy it up later, if needed. If you plan to create a new article, please read and follow the [[article naming conventions]].<br />
<br />
==Articles that apply to more than one application==<br />
* If the article applies to both the Mozilla Suite and Firefox/Thunderbird, create it and edit it for Mozilla Suite and Firefox/Thunderbird, if you can. A lot of articles written talk exclusively about Firefox or Thunderbird, yet they often apply to Mozilla Suite too. This is a shame, because Mozilla Suite is in need of more people creating resources for it and converting old content to it.<br />
* Not every article that ''could'' be written to cover both the Mozilla Suite and Firefox/Thunderbird ''should'' be written this way. In some cases it might make the article excessively messy, especially if it refers to a series of steps or menu choices that differ in the Mozilla Suite and Firefox/Thunderbird ([[Multiple SMTP servers (Thunderbird) |example]]). In such cases it's probably best not to write combined product articles. Use your best judgment.<br />
* If you're creating a new article and you're not sure if it applies to more than one application (e.g., you're writing a Firefox article but you're not an experienced Mozilla Suite user), go ahead and write it for just one product. Someone else can edit it later if needed.<br />
<br />
==Commonly used names==<br />
* '''Application names''': <br />
** '''Use''' "Firefox" (but not "FireFox"), "Thunderbird", and "[the] Mozilla Suite" as the application names in articles' titles and text. '''Don't use''' "Mozilla Firefox", "Mozilla Thunderbird", "Mozilla" (meaning the Suite), "[the] Mozilla Application Suite", "[the] Suite" or "Seamonkey". Try to avoid "Mozilla Mail" when "[the] Mozilla Suite" will suffice, especially in articles that also apply to Thunderbird.<br />
** Layout issues should use "Gecko" as the application name.<br />
<br />
* '''OS names'''.<br />
** ''Windows.'' Use "Windows" when referring to the whole family of Microsoft Windows operation systems. For specific versions use: "Windows 95", "Windows 98", "Windows ME", "Windows NT", "Windows 2000", "Windows XP", "Windows XP SP2". When combining names, use forward slashes, e.g.: "Windows 2000/XP".<br />
** ''Linux.'' Use "Linux" when referring to *nix-like systems. Do not use "GNU/Linux" or any other name. If you absolutely need to use a name of a particular distribution, note your choice (along with the link to the article) in [[Talk:In-House Style]].<br />
** ''Mac OS''. Use "Mac OS X", not "Mac OSX", "MacOS X" or any other name.<br />
<br />
==Common terms==<br />
Use these terms as listed here (sans quotes). Terms like "Profile Manager" and "Bookmarks Toolbar" refer to named product features and function as proper nouns. Note the capital letters.<br />
<br />
*'''General''':<br />
** ''Good:'' "JavaScript", "Profile Manager", "Status Bar"<br />
** ''Bad:'' "Javascript", "profile manager", "statusbar"<br />
<br />
*'''Browser-related''':<br />
** ''Good:'' "bookmark(s)", "Bookmarks Toolbar", "cache", "Location Bar", "plugin", "Search Bar"<br />
** ''Bad:'' "favorites", "Links Toolbar", "Temporary Internet Files", "address bar", "plug-in", "search box"<br />
<br />
*'''Mail-related''':<br />
** ''Good:'' "e-mail", "Junk Mail Controls", "Local Folders"<br />
** ''Bad:'' "Email", "junk mail controls", "local folders"<br />
<br />
==Special punctuation and formatting==<br />
* '''Menu sequences''': Use "arrows" to denote menu order (e.g. "Tools -> Options"), and place a space either side of the arrow to facilitate line breaks. Use quotation marks around the whole menu sequence. In cases where menu sequences differ by OS, it may be helpful to include a link to [[Menu differences in Windows, Linux, and Mac]] within the menu sequence itself (e.g., "[[Menu differences in Windows, Linux, and Mac|Tools -> Options]] -> Advanced").<br />
* '''Keyboard and mouse actions''': left-click, right-click etc. are hyphenated and uncapitalized; Shift, Ctrl, Alt etc. have their first letter capitalized (and only their first letter); key combinations are written using "+" so that "hold down Ctrl and press 'D'" should be written "Ctrl+D".<br />
* '''Keyboard shortcuts''': Put quotation marks around keyboard shortcuts (e.g., "Ctrl+PageDown")<br />
* '''Path names''': Enclose these in <nowiki><tt></nowiki> tags so that they will appear in a monospace font (e.g., <tt>C:\Program Files\Mozilla Firefox\firefox.exe</tt>). Folders whose location varies (e.g., "profile folder" and "installation directory") can be enclosed in angle brackets when part of a path (e.g., <tt><profile folder>/chrome/overlayinfo/</tt>).<br />
* '''Directory & file names''': In general, put these in quotation marks when they are used in a sentence but are not connected to a longer pathname (e.g., "Go to the "chrome" folder in your profile folder and find the "userChrome.css" file"). Exceptions: you can omit the quotation marks around well-known file names (e.g., prefs.js or user.js), second and subsequent instances of a file name that appears multiple times in the same article, or file names used in Dev articles (you can use <nowiki><tt></nowiki> instead).<br />
* '''Mail folders''' (as listed in the folders pane): Write these as simply Inbox, Sent, Junk, Trash, etc., without italics or quotation marks; the corresponding files for each should be treated like other file names and normally be written in quotation marks (e.g., "Inbox", "Sent", "Junk", "Trash", etc.).<br />
<br />
==Tables==<br />
Use [http://meta.wikimedia.org/wiki/Help:Table Mediawiki-syntax tables] for tables, together with the <code><nowiki>{{prettytable}}</nowiki></code> template (see [[Template:Prettytable]]). The template is a modified version of [http://meta.wikimedia.org/wiki/Template:Prettytable meta.wikipedia.org's]. [[Product comparison matrix | For example]],<br />
<nowiki>{| {{prettytable}}</nowiki><br />
! || Odds || Evens<br />
|-<br />
! Row 1 <br />
| 1 || 2<br />
|-<br />
! Row 2<br />
| 3 || 4<br />
|-<br />
! Row 3<br />
| 5 || 6<br />
<nowiki>|}</nowiki><br><br />
<br />
This produces<br><br />
{| {{prettytable}}<br />
! || Odds || Evens<br />
|-<br />
! Row 1 <br />
| 1 || 2<br />
|-<br />
! Row 2<br />
| 3 || 4<br />
|-<br />
! Row 3<br />
| 5 || 6<br />
|}<br />
<br />
==Templates==<br />
There are numerous templates available to insert standardized content and/or formatting into pages. For instance, if you come across an article that needs a formatting makeover in order to follow the style guidelines listed on this page, you can insert <nowiki>{{cleanup}}</nowiki> at the top of the article. This will expand to the message shown [[Template:Cleanup | here]].<br />
<br />
For a list of useful templates and further explanation, see [[Rules/Templates]].<br />
<br />
==Other style considerations==<br />
* Don't start too many small, idiosyncratic paragraphs. If several paragraphs each consist of a couple of sentences with only a few lines length, try to combine them into a single paragraph.<br />
* Use bolding and italics only when absolutely necessary.<br />
* Don't overdo linking. Since links stand out visually, they can disrupt the reader's flow and become a distraction rather than an aid. Try not to put the same link more than once in a single logical unit of an article (e.g., a section of a tutorial). For example, if you mention "profile folder" several times, link only the first one, or the one that's relating to something technical, at a point where the reader might logically want to read up on the specifics.<br />
* Headers/subheaders within articles should be capitalized in the same way as [[Article naming conventions|article titles]].<br />
* Use <nowiki>==See also==</nowiki> when linking to articles on the KB. Use <nowiki>==External links==</nowiki> to link to web pages outside of the Knowledge Base.<br />
* Use the dash and hyphen correctly [http://en.wikipedia.org/wiki/Dash] [http://en.wikipedia.org/wiki/Hyphen]. When using dashes and hyphens, you should not include white space around them. For example, use &ldquo;9&ndash;16&rdquo; and &ldquo;Firefox&mdash;and Mozilla&mdash;can be used&rdquo; which are achieved using &ldquo;9&amp;ndash;16&rdquo; and &ldquo;Firefox&amp;mdash;and&rdquo;.<br />
* "Backup" is a noun; "back up" is the verb. When you back up your mail, you're making a backup.<br />
* Don't capitalize entire words.</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk&diff=22404Talk2006-01-30T18:43:27Z<p>Wintogreen: removing irrelevant wikipedia material, etc.</p>
<hr />
<div>{{org}}<br />
<br />
==How to use Talk==<br />
<br />
In the sidebar of every page there is a link titled "Discussion" which links to the Talk page for that article. Talk pages allow you to discuss the content of articles without cluttering up the article itself.<br />
<br />
Examples of things to mention on Talk pages:<br />
* Suggestions for improving the article. (Note: for user-support questions, please use the [http://forums.mozillazine.org/ MozillaZine forums] instead.)<br />
* Problems you have with the current content of the article.<br />
* Possible solutions to edit wars.<br />
<br />
Please note that it is generally considered bad ettiquette to delete or alter the comments of another user. While this is perfectly fine on the rest of the wiki, doing so on a Talk page disrupts the conversation.<br />
<br />
Remember to sign and date your comments. Typing "<nowiki>~~~~</nowiki>" will do this automatically.<br />
<br />
When you are in the Talk page, clicking on the "Article" link will take you back to the main article.<br />
<br />
== User talk pages ==<br />
<br />
Your user page has a Talk page as well, and that one has some special features. For one thing, there is a link to it in the sidebar (if you use a "skin" other than the default it may be somewhere else). Also, if edits are made to it by others, the text '''You have new messages''' will appear at the top of the page. These pages can be used for occasional personal communication among users; but note that these pages are public. If you want to communicate privately, use e-mail.<br />
<br />
To write in another user's talk page, click the ''Discussion'' link on your sidebar when you view the user page (which you can do by clicking on a user's nickname). On the list of recent changes and on your watchlist, you can directly access a user's Talk page by following the (Talk) link behind the user's name.<br />
<br />
=="Post a comment" feature==<br />
For editing a talk page, one can optionally use the "Post a comment" feature, but only for a new thread and for a reply to be put at the bottom of the last thread. To post a comment in this way, click on the "+" link in the sidebar.<br />
<br />
*For a new thread, fill in the "Subject/headline" box. Then the edit summary will automatically be the same as the new section editing.<br />
<br />
*For a reply to be put at the bottom of the last thread, do not fill in the "Subject/headline" box. In this case it is not possible to supply an edit summary. Instead, edit the previous thread.<br />
<br />
When using "Post a comment", an edit conflict is impossible. However, in the case that you are not starting a new thread but replying to an existing one, your response may be appended to a newly created post that was added while you wrote yours. It is therefore generally recommended to use section editing to respond, and "Post a comment" to start new threads. If your comment is accidentally misplaced, just edit the page and move it.<br />
<br />
== Example ==<br />
<br />
This article is great. --[[User:Adam Conover|Adam Conover]] 18:20 Jan 30, 2003 (UTC)<br />
:No it isn't! --[[User:hao2lian|hao2lian]] 18:38 Jan 30, 2003 (UTC)<br />
::Yes it is! --[[User:Heroist|Heroist]] 18:40 Jan 30, 2003 (UTC)<br />
<br />
:::I was talking to Adam Conover! --[[User:hao2lian|hao2lian]] 18:56 Jan 30, 2003 (UTC)<br />
<br />
I like wojahowicz better. --[[User:Adam Conover|Adam Conover]] 12:20 Jan 31, 2003 (UTC)<br />
<br />
:Now, now. --[[User:hao2lian|hao2lian]] 12:33 Jan 31, 2003 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk&diff=22399Talk2006-01-30T18:24:02Z<p>Wintogreen: /* How to use Talk */ tidy up</p>
<hr />
<div>{{org}}<br />
<br />
==How to use Talk==<br />
<br />
In the sidebar of every page there is a link titled "Discussion" which links to the Talk page for that article. Talk pages allow you to discuss the content of articles without cluttering up the article itself.<br />
<br />
Examples of things to mention on Talk pages:<br />
* Suggestions for improving the article. (Note: for user-support questions, please use the [http://forums.mozillazine.org/ MozillaZine forums] instead.)<br />
* Problems you have with the current content of the article.<br />
* Possible solutions to edit wars.<br />
<br />
Please note that it is generally considered bad ettiquette to delete or alter the comments of another user. While this is perfectly fine on the rest of the wiki, doing so on a Talk page disrupts the conversation.<br />
<br />
Remember to sign and date your comments. Typing "<nowiki>~~~~</nowiki>" will do this automatically.<br />
<br />
When you are in the Talk page, clicking on the "Article" link will take you back to the main article.<br />
<br />
== What is it used for? ==<br />
<br />
The purpose of a talk page is to help to improve the contents of the main page, from an encyclopedic point of view. Questions, challenges, excised text (due to truly egregious confusion or bias, for example), arguments relevant to changing the text, and commentary on the main page is all fair play. In other words, talk about the article, not about the subject.<br />
<br />
That said, we are all fallible creatures, so it's entirely natural that a bit of partisan wrangling takes place on talk pages - and occasionally this even leads to improvements in the article! So there's a fair degree of tolerance, and most editors succumb to a bit of wrangling from time to time.<br />
<br />
== User talk pages ==<br />
<br />
Your user page has a talk page as well, and that one has some special features. For one thing, there is a link to it in the header next to your name (if you use a "skin" other than the default it may be somewhere else). Also, if edits are made to it by others, the text '''You have new messages''' will appear at the top of the page. These pages can be used for occasional personal communication among users; but note that these pages are public. If you want to communicate privately, use e-mail.<br />
<br />
To write in another user's talk page, click the ''Discuss this page'' link on your sidebar when you view the user page (which you can do by clicking on a user's nickname). On the list of recent changes and on your watchlist, you can directly access a user's talk page by following the (Talk) link behind the user's name / [[IP address]].<br />
<br />
=="Post a comment" feature==<br />
For editing a talk page, one can optionally use the "Post a comment" feature, but only for a new thread and for a reply to be put at the bottom of the last thread.<br />
<br />
*For a new thread, fill in the "Subject/headline" box. Then the [[edit summary]] is automatically the same as the new [[section header | section editing]].<br />
<br />
*For a reply to be put at the bottom of the last thread, do not fill in the "Subject/headline" box. In this case it is not possible to supply an edit summary. Instead, edit the previous thread.<br />
<br />
When using "Post a comment", an edit conflict is impossible. However, in the case that you are not starting a new thread but replying to an existing one, your response may be appended to a newly created post that was added while you wrote yours. It is therefore generally recommended to use [[section editing]] to respond, and "Post a comment" to start new threads. If your comment is accidentally misplaced, just edit the page and move it.<br />
<br />
== Example ==<br />
<br />
This article is great. [[User:Adam Conover|Adam Conover]] 18:20 Jan 30, 2003 (UTC)<br />
:No it isn't! --[[User:hao2lian|hao2lian]]<br />
::Yes it is! --[[User:Heroist|Heroist]]<br />
<br />
:I was talking to [[User:Adam Conover|Adam Conover]]! --[[User:hao2lian|hao2lian]]<br />
<br />
I like wojahowicz better. [[User:Adam Conover|Adam Conover]]<br />
<br />
:::Now, now. [[User:hao2lian|hao2lian]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Rules_and_guidelines&diff=22398Rules and guidelines2006-01-30T18:10:33Z<p>Wintogreen: linkify 2 pages</p>
<hr />
<div>{{org}}<br />
Welcome, new and existing editors! Your contributions of Mozilla-related knowledge are most welcome, and you don't need to be an &ldquo;expert&rdquo; to help out. In particular, if you have come to the Knowledge Base from the [http://forums.mozillazine.org forums] after having a question answered or a problem solved, you are encouraged to write up anything that you learnt there, even if you didn&rsquo;t fully understand why the solution works.<br />
<br />
Don&rsquo;t feel daunted by the rules below; although it helps if you follow them, there will always be other editors willing to tidy your contributions if you don&rsquo;t have the time to read all the guidelines in the links below. The important thing is getting your contributions here in the first place!<br />
<br />
Of course, if you&rsquo;re planning on becoming a regular contributor then you should try to follow the rules more closely.<br />
<br />
==Practise editing pages==<br />
Play with the wiki system on the following pages, and only on them.<br />
* A [[sandbox|sandbox]] for showing off the wiki's features.<br />
* Another [[misc:testpage | test page]] - Now with extra markup tests!<br />
* If you want to do some silly tests using a page use [[this]] page.<br />
<br />
==Editing courtesy==<br />
* Any time you edit a page, please add a short comment in the "Summary" field about the change you made. This makes it easier for others to see what has changed. Importantly, it can help make it easier for us to distinguish Knowledge Base vandalism from legitimate contributions.<br />
* Document reasons for potentially controversial changes on the [[Talk]] pages.<br />
* Accept changes to your entries in a spirit of helpfulness; experienced editors will often make changes to ensure that an article conforms to the rules. Of course, discussion relating to the changes is welcome on the corresponding Talk pages.<br />
* If you find yourself wanting to change an entry back to an earlier revision, ask yourself if the current version had a useful purpose, and whether it really is necessary to change it back.<br />
* If someone consistently makes certain types of mistakes or formatting quirks, consider placing a message in their User Talk page.<br />
<br />
==Avoid superfluous information==<br />
* In Knowledge Base articles, please do not insert signatures, links to sites that are not related to Mozilla products, or other superfluous information. If you want to give a link to your own personal website, for example, then put it in your User page, not in the article. In short, if the information or link is not directly related to the topic of the article, then don't include it in the article.<br />
* Of course, signatures are welcome and helpful in the Talk pages, so please do use them there.<br />
<br />
==Creating new articles==<br />
Before you create a new article in the Knowledge Base, check to see if the topic hasn't already been covered somewhere. Do a search and browse the relevant articles. You don't want to waste your time by adding information that already exists.<br />
<br />
Please read and follow the [[article naming conventions]] when creating new articles or moving existent ones. You don't have to read that if you only edit existing pages.<br />
<br />
To actually create the new article, visit the [[Sandbox]] and create a link to your proposed article, such as <nowiki>[[My new article]]</nowiki>. Preview the Sandbox page, and then click on the link. This will take you to the (currently empty) page for your article, where you can add your content.<br />
<br />
==Style guidelines==<br />
Please have a look at [[In-house style]]. We're trying to give the Knowledge Base a uniform look, and you can help by following these guidelines as much as possible.<br />
<br />
==Categorizing articles==<br />
To allow people to find information more easily, it is helpful to use [[Rules/Categories | categories]] when editing or creating articles.<br />
<br />
==Talking to authority==<br />
* [[Pages voted for deletion]] -- get pages deleted<br />
* [[Vandalism]] -- get vandals banned<br />
* [[Todo list for kerz]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Global_Inbox&diff=22389Global Inbox2006-01-30T17:10:42Z<p>Wintogreen: /* Change the destination Inbox */ fix for TB 1.5</p>
<hr />
<div>Beginning with version 0.8, Thunderbird now has a '''Global Inbox''' feature that allows you to have your mail from multiple POP accounts go into a single Inbox, in [[Local Folders]]. You can choose to have all or only some of your POP accounts use the Global Inbox, as you wish. Each account that does not use the Global Inbox will have its own set of folders, including its own Inbox, displayed in the folders pane. Accounts that do use the Global Inbox will not have their own folders displayed in the folders pane; instead, all you will see is the single set of folders in Local Folders.<br />
<br />
__TOC__<br />
<br />
==When creating a new account==<br />
<br />
When you create a new POP mail account in Thunderbird, the Account Wizard will ask if you want to use the Global Inbox for that account. If you do, then make sure that the box for this feature is checked. If you don't, then make sure the box is unchecked.<br />
<br />
==Changing the Global Inbox setting for an existing account==<br />
To change the Global Inbox setting for an existing account, you need to follow three simple steps.<br />
<br />
===Change the destination Inbox===<br />
Go to "[[Menu differences in Windows, Linux, and Mac|Tools -> Account Settings]] -> Server Settings" and click on the "Advanced" button. A dialog box will then pop open.<br />
<br />
To set the account to use the Global Inbox, select "Global Inbox (Local Folders Account)" and click "OK". <br />
<br />
:'''Important''': if the account already has messages in the Inbox or other folders, you should copy or move these messages into Local Folders '''before''' setting the account to use the Global Inbox. If you don't copy or move the messages into Local Folders and you set the account to use the Global Inbox, the account will no longer be displayed in the folders pane and you will not be able to access those messages unless you go back and undo the Global Inbox setting. <br />
<br />
To set the account to not use the Global Inbox, select either "Inbox for this server's account" or "Inbox for different account" and click "OK".<br />
<br />
===Check settings for other folders and filters===<br />
After you have changed the account's setting for which Inbox to use, see if any of the following need to be changed:<br />
* Go to "Tools -> Account Settings -> Copies & Folders", and look at the destination folders for Sent, Drafts, and Templates. Make sure that the messages for each will be stored in your preferred folder locations. <br />
* If you are using [[Junk Mail Controls|junk-mail filtering]] for the account, go to "Tools -> Junk Mail Controls" and verify that the folder selected for Junk messages is the one you want to use.<br />
* If you have set up any [[Filters (Thunderbird)|filters]], go to "Tools -> Message Filters" and make sure that they will work properly with your new Inbox configuration. Especially important if you are changing an account so that it will start using the Global Inbox: if you have set up any filters that sort messages '''into''' any of the folders for the account, you should disable/delete those filters or change the destination folders.<br />
<br />
===Exit and restart Thunderbird===<br />
Important: exit Thunderbird and restart '''before downloading mail''' into any account whose Inbox/Global Inbox setting you've changed. If you do not exit and restart, messages might continue to download into their "old" locations (e.g., into the individual account Inbox rather than the Global Inbox).<br />
<br />
==Other information==<br />
* Accounts that use the Global Inbox are sometimes called "deferred" accounts, and it is possible to create deferred accounts that do not use Local Folders for the Global Inbox. For example, if you have three Gmail accounts, you could set up two of them to store their mail together with the mail for the other Gmail account but ''outside'' of Local Folders. To do so, follow the procedure above for setting the destination Inbox, but instead of selecting "Global Inbox (Local Folders Account)", select "Inbox for a different account" and then from the dropdown list choose the account you want to use.<br />
* For deferred accounts, if you go to "Tools -> Account Settings... -> [account name] Server Settings", you will see that "Local directory" does ''not'' point to the actual location in your [[profile folder]] where the mail is stored. This is normal and necessary because certain files for each deferred account need to be stored separately from the shared mail files. (For instance, each POP3 account has its own file called "popstate.dat" that keeps track of which messages have been downloaded from the server. Account-specific [[Filters (Thunderbird) | message filters]] are likewise stored in a separate folder for each account.)<br />
<br />
[[Category:Organizing and finding messages (Thunderbird)]]<br />
[[Category:E-mail account setup (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Global_Inbox&diff=22388Talk:Global Inbox2006-01-30T17:08:29Z<p>Wintogreen: /* Instructions about 'POP tab' don't apply */ good catch</p>
<hr />
<div><br />
<br />
== Instructions about 'POP tab' don't apply ==<br />
<br />
Attempting to comment, hope this is the right place for this...<br />
<br />
At [http://kb.mozillazine.org/Thunderbird_:_FAQs_:_Global_Inbox#Changing_the_Global_Inbox_setting_for_an_existing_account] it states: '''''Change the destination Inbox''' <ret> Go to "Tools -> Account Settings -> Server Settings", click on the "Advanced" button, and then in the dialog box that pops up click on the "POP" tab. ''<br />
<br />
I'm using Thunderbird 1.5 Mac, and no "POP tab" appears. <br />
<br />
Also, the dialogs do SEEM to apply, but when I choose 'Global Inbox/OK', I get a 'Defer Account?' alert that would seem to be confusing for nearly anyone - but that's another issue.<br />
<br />
:Right you are, about the POP tab. It was there under the 1.0.x versions, along with an SMTP tab. In 1.5 the SMTP picker got moved in the account's mail identity panel and so there was no more need for either tab. I'll fix the article. Thanks for pointing it out. --[[User:Wintogreen|wintogreen]] 17:08, 30 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22386Talk:Profile folder2006-01-30T16:58:02Z<p>Wintogreen: moving this Q up to where it fits better</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome/userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome/userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
::::I agree with Wintogreen. Firstly, I like the idea of adding the word "folder" to the end of article titles concerning subfolders of the profile folder. Secondly, I think that adding the folder path to the article title would be a bit of an overkill, as would creating mini-categories, ''unless'' filenames are not unique within the profile folder tree. In the latter case, we have no choice but to have some method of differentiation. (Ideally, we should keep things simple; "userChrome.css" has to be better than "chrome/userChrome.css". Incidentally, I'm not big on lumping userChrome and userContent together, although I can see the benefit of not needing to teach people CSS in two separate articles; what do others think?) --[[User:Mozcerize|Mozcerize]] 16:37, 30 January 2006 (UTC)<br />
<br />
What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --[[User:Wintogreen|wintogreen]] 16:36, 30 January 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Whether it requires other files to work (like the password file)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22383Talk:Profile folder2006-01-30T16:36:10Z<p>Wintogreen: /* Information included (brainstorming) */</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome/userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome/userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
:What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --[[User:Wintogreen|wintogreen]] 16:36, 30 January 2006 (UTC)<br />
* Purpose<br />
* Whether it requires other files to work (like the password file)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22382Talk:Profile folder2006-01-30T16:27:49Z<p>Wintogreen: /* Proposed hierarchy */ files in folders</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome/userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome/userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
::I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--[[User:Np|Np]] 16:11, 30 January 2006 (UTC)<br />
:::I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --[[User:Wintogreen|wintogreen]] 16:27, 30 January 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Whether it requires other files to work (like the password file)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
* Whether it exists by default<br />
: ^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile ([[prefs.js]] and [[user.js]], for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? [[User:Alice Wyman|Alice Wyman]] 16:01, 30 January 2006 (UTC)<br />
:: Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--[[User:Np|Np]] 16:14, 30 January 2006 (UTC)<br />
:::I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the ''only'' place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --[[User:Mozcerize|Mozcerize]] 16:25, 30 January 2006 (UTC)<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)<br />
: I agree with this decision. --[[User:Mozcerize|Mozcerize]] 16:21, 30 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22375Talk:Profile folder2006-01-30T15:53:52Z<p>Wintogreen: /* Proposed hierarchy */ what to do with folders</p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)<br />
::: I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the [[Issues with Firefox]] page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the [[Knowledge_Base_changes]] page regarding the [[:Category_talk:Preferences]] guidelines. [[User:Alice Wyman|Alice Wyman]] 14:12, 30 January 2006 (UTC)<br />
===Proposed hierarchy===<br />
Profiles<br />
|-Profile contents (Firefox)<br />
|-bookmarks.html<br />
|-localstore.rdf<br />
|-chrome/userChrome.css<br />
|-(...)<br />
|-Profile contents (Thunderbird)<br />
|-localstore.rdf<br />
|-abook.mab<br />
|-chrome/userChrome.css<br />
|-(...)<br />
(What to do with folders?)<br />
<br />
:How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --[[User:Wintogreen|wintogreen]] 15:53, 30 January 2006 (UTC)<br />
<br />
===Information included (brainstorming)===<br />
* Name<br />
* Purpose<br />
* Whether it requires other files to work (like the password file)<br />
* The consequences of deleting it<br />
* Whether it's possible/advisable/how to move it to another profile<br />
* Versions that it appears in<br />
* Previous names/locations that did the same thing<br />
<br />
==Files outside the "Profiles" folder==<br />
I removed the entry for <tt>mailnews.js</tt> ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. [[User:Alice Wyman|Alice Wyman]] 15:12, 30 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Profile_folder&diff=22364Talk:Profile folder2006-01-30T13:22:09Z<p>Wintogreen: </p>
<hr />
<div>'''The content of this article was migrated manually from [[Profile Folder]]. For previous article Talk and Talk History, see [[Talk:Profile Folder]] and [http://kb.mozillazine.org/index.php?title=Talk:Profile_Folder&action=history], respectively. For previous article History, see [http://kb.mozillazine.org/index.php?title=Profile_Folder&action=history]. ''' --[[User:Wintogreen|wintogreen]] 16:19, 26 December 2005 (UTC)<br />
<br />
----<br />
<br />
=="Profile files" Category==<br />
What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--[[User:Np|Np]] 18:25, 29 January 2006 (UTC)<br />
: I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --[[User:Mozcerize|Mozcerize]] 11:04, 30 January 2006 (UTC)<br />
::Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --[[User:Wintogreen|wintogreen]] 13:22, 30 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Start_Address_Book_from_command_line&diff=22353Start Address Book from command line2006-01-30T02:10:44Z<p>Wintogreen: no need for full paths here, actually</p>
<hr />
<div>You can bring up Mozilla Suite's or Thunderbird's Address Book using the command-line switch "-addressbook" [http://www.mozilla.org/docs/command-line-args.html].<br />
<br />
For example, on Windows:<br />
mozilla.exe -addressbook<br><br />
thunderbird.exe -addressbook<br />
<br />
And on Mac OS X:<br />
/Applications/Mozilla.app/Contents/MacOS/mozilla -addressbook<br><br />
/Applications/Thunderbird.app/Contents/MacOS/thunderbird -addressbook<br />
<br />
You can run these commands in whatever command-line interface your have on your OS (Command Prompt on Windows, Terminal on Mac OS X, et cetera).<br />
<br />
===See also===<br />
* [[Command line arguments (Thunderbird)]]<br />
<br />
[[Category:Address Book (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Knowledge_Base_changes&diff=22296Knowledge Base changes2006-01-28T16:30:12Z<p>Wintogreen: /* Question&mdash;how to use "SeaMonkey" in the kb from now? */</p>
<hr />
<div>{{org}}<br />
==Temporary introduction==<br />
This page has been created for several reasons.<br />
<br />
*It would be nice to have a place where new editors can introduce themselves and meet existing editors.<br />
*It would be good to allow new editors to safely propose content changes (minor or major) prior to implementing them.<br />
*It would be good to have a central location to discuss the style, content and organisation of this Knowledge Base. (Some of the ideas in [[Talk:Knowledge Base]] can be migrated here, leaving that page solely for discussion of the front page article itself.<br />
*This page is an attempt to address recent incidents that have occured on the KB where some groups of editors have been unaware of major changes being made by other groups of editors.<br />
<br />
We intend to place a link to this page in the "welcome to new editors" paragraphs found on the front page and from the other "entrance" pages such as [[Firefox]] and [[Thunderbird]] if it is deemed useful.<br />
<br />
We anticipate this page being the primary place to announce new suggestions. Please visit it regularly!<br />
<br />
==Welcome to new editors==<br />
Hello! Great to have you here. Please add a comment here :-)<br />
<br />
* Hello Knowledge Base! FJ reporting to duty! *bows at all* [[User:FatJohn|FatJohn]] 11:30, 3 January 2006 (UTC)<br />
<br />
==Hot topic&mdash;Making things less daunting for new editors==<br />
Several new editors (or potential editors) have felt a bit daunted by the [[rules]] for contributing. I think this is a shame; we want their contributions! (The rules are fairly comprehensive and are written formally; this is for the benefit of regular contributors. But it was never anyone's intention to discourage new editors.) I have added an introduction to the [[rules]] page, which states that they don't need to read everthing thoroughly. This could be controversial; please state your view here! Should we include that sentiment in other places too? And should we put a sticky in the forums which tries to bring new editors to the KB? --[[User:Mozcerize|Mozcerize]] 13:10, 8 January 2006 (UTC)<br />
:Looks good; you have a knack for writing these welcome intros. Where else would that sentiment be included? Instead of a forum sticky, I'd just use a regular thread in the General forums; the regulars will see it. A few suggestions: (1) The "Please don't be offended..." sentence can come out or be merged into the similar point in the "Editing courtesy" section. (2) The "Avoid superfluous information" section could go into In-house style. (3) The "Test editing pages" section could come to the very top, above "Editing courtesy", as a way to invite people to take the plunge into editing. (4) "Talking to authority" should come out; those links are all available in kb Organization category and aren't rules in the first place. (5) [[Rules/Templates]] should be renamed because those templates aren't rules; they're editing shortcuts and should be presented as such. --[[User:Wintogreen|wintogreen]] 14:36, 8 January 2006 (UTC)<br />
::I'll look into these suggestions soon! --[[User:Mozcerize|Mozcerize]] 17:50, 10 January 2006 (UTC)<br />
<br />
I suggest the rules be modified to state that you shouldn't post a notice on a page unless it adds value to the reader. For example, posting a notice stating that the name of the knowledge base page is in error (when its actually due to a limitation of the wiki software) just causes confusion and annoys the person who wrote the article. The reader doesn't care that we're using Wiki software. Note that I'm not arguing against a notice that an article needs rewriting. The reason I'm mentioning this in this section is because behavior that seems perfectly appropiate to somebody steeped in the wiki culture can be upsetting to a new editor who has never had to deal with collaborative writing with strangers.<br />
<br />
I'm not a wiki person. It was easy to pick up what I needed to know to edit knowledge base articles before we switched to categories. Its more difficult now. An example - I need to create a new category. I read Rules/Categories and it wasn't clear to me how to create a new category, though I understood how to make a category a subcategory because that didn't require any background knowledge. Please think about the barrier to entry you're accidentally creating by assuming a new editor has a wiki background. <br />
<br />
I don't think creating a thread will help attract new editors. I suggest you consider converting MozillaZine_Knowledge_Base:Formatting into a short primer on what you need to know to be an editor. The current article does a good job of covering what you need to know about formatting. But it <br />
doesn't cover other common tasks such as how you create a new article or how to categorize it. Yes, there are links to wiki documentation where you can find that but its rather overwhelming for somebody who may know a little HTML or bbcode and is not used to reading rules, in-house style guides, naming conventions etc. while learning yet another formatting syntax. Think of all that we're implying a person should read before doing something small such as update an existing article for a new version. Especially since they really don't need to deal with most of those topics until they create a new article, if they make an attempt to mimic what they see in the article they're editing. I think its telling that some of our most prolific forum posters such as Daifne, SKopischke, GordMcFee and Mr. Liu have never touched the knowledge base as far as I can tell. The current approach seems designed to tell you everything that you need to know to do it right in order to minimize cleanup by other editors. I think we should increase the risk that we'll have to cleanup after a new editor for a while if that makes it easier to lower the barrier to entry (whether its real or perceived).<br />
<br />
I'm suggesting that we make it easy for them to get started by letting them get started using just the primer, let them learn more of the conventions/customs (documented in the rules, guides etc.) later on as they tackle bigger tasks, and try to avoid giving them the impression they need to learn everything before they can do anything. Once thats in place its also easier for somebody to encourage somebody to contribute. <br />
<br />
It might also help if one or two names (perhaps Wintogreen?) were mentioned in the primer as volunteers that new editors are encouraged to contact via private messages for advice if they need it. --[[User:Tanstaafl | Tanstaafl]] 3:30 AM January 16, 2006 (PMT)<br />
<br />
<br />
I took the liberty of expanding the [[MozillaZine Knowledge Base:About|About]] page, in particular the "Contributing to the KB" section. If someone could please review it and revise where you think it can be improved, that'd be great. Note that I also added a "Need help with the wiki?" section at the end of the [[Help wanted]] page. That's my way of saying I don't want to be a designated go-to guy. ;-) --[[User:Wintogreen|wintogreen]] 19:14, 19 January 2006 (UTC)<br />
<br />
==Hot topic&mdash;replacing the FAQs and Issues pages with category navigation==<br />
Discussion of this proposal can be found on [[Talk:Rules/Categories]]). Some editors were not aware of this discussion (see [[Talk:Issues with Firefox]] and [[Talk:Rules/Categories#Flattening the Thunderbird categories]]). This was the main motivation for creating this page.<br />
<br />
To summarize the situation so far:<br />
<br />
Part of the motivation for implementing categories was to avoid the following situation which occurred with the original FAQs, Issues and Tips pages: article links had to be maintained manually; some articles appeared on more than one page; some articles didn't appear on any page. The result was that people had to look at all three pages to makes sure they didn't miss anything, and then perform a search as well. With categories, the danger that an article was never linked to from anywhere was removed, since category automatically list the articles. There was no opposition to removing the Tips pages.<br />
<br />
The suggestion to temove the FAQs and Issues pages was more controversial. Indeed, the problem with relying solely on category listings is that ''logical order'' is lost. The initial solution proposed was to use the editable part at the top of the category pages to recreate some logical order by factoring in parts of the FAQs and Issues pages.<br />
<br />
:My current opinion on this is that the FAQ and Issues pages should be kept, because they contain more info that could sensibly be placed in the category pages. However, I do think that they should both contain prominant links to the category pages, notifying the reader that there is more info on the KB than the selection of articles advertised on the FAQ and Issues pages. Indeed, I would suggest renaming "Issues " to "Common Issues with Firefox" to emphasise the fact that the Issues page is just a selection. --[[User:Mozcerize|Mozcerize]] 15:00, 2 January 2006 (UTC)<br />
<br />
:: First, thanks for the new discussion area and for the invitation to add comments. I've already added some comments to the [[Talk:Issues with Firefox]] page, back when it was first removed. I never did see the justification for removing either page, even if they are no longer linked from the front page. (I took it upon myself to restore them... I'm sorry it I stepped on anyone's toes but I was totally unaware of any discussion going on or a decision to remove the two pages. I strongly believe that both pages should be kept as they're a very handy way to organize and locate information, especially the FAQs page, which is unique in that the collection of links isn't duplicated anywhere else, alphabetically or not. Both pages are good places to include links to forum topics, release notes or other external links when there is no KB article covering the topic, plus the link descriptions give much more information than a simple title page link. I'm willing to help keep both pages organized and updated since I refer to them both so often. As far as the [[Issues with Firefox]] page, I've already pointed out in the intro that, "A link to an alphabetized list of current articles in the Category, Issues (Firefox) can be found at the end of this article." It might be a good idea to eliminate some of the less common issues on the page, such as the entire "Versions older than 1.0" section, and to emphasize that the page is a collection of "Common Firefox Issues" and is not exhaustive. I don't see the need for a new name but if someone else whats to rename the page "Common Firefox Issues" or similar, that's fine with me. [[User:Alice Wyman|Alice Wyman]] 20:47, 2 January 2006 (UTC)<br />
<br />
:::''"I'm sorry it I stepped on anyone's toes&hellip;."'' Not at all. Thanks for the points you've raised. The links to the forums and other offsite pages are indeed important. I was weighing up the idea of creating KB articles which act as wrappers for offsite links, that is, they have a useful title but their content is just a link. Ultimately, it would be good to have the info that they point to actually transferred to the article. (Anybody got a free week? ;-) I don't claim that this is an urgent task, but it would be good to have the offsite info represented somehow in the category listings. --[[User:Mozcerize|Mozcerize]] 11:25, 4 January 2006 (UTC)<br />
::::I made some changes to both the [[Firefox FAQs]] and [[Issues with Firefox]] pages today and made a note of this discussion on the Talk pages for each article. [[User:Alice Wyman|Alice Wyman]] 16:40, 7 January 2006 (UTC)<br />
:::::That's great; thanks! --[[User:Mozcerize|Mozcerize]] 12:15, 8 January 2006 (UTC)<br />
<br />
One of the current problems is that some of the categories mingle articles written for all of the products, even though you may have navigated there by selecting articles for one product. Somebody looking for information on Thunderbird privacy and security for example shouldn't see stuff such as Disabling autocomplete (Firefox), Mozilla Suite : FAQs : Mozilla Security or Parental controls. Ditto for navigating to Configuration::Preferences for Thunderbird and finding dozens of articles on preferences that Thunderbird doesn't support. I suggest we create a strategy for how to deal with this before creating a SeaMonkey category, which will just make it worse. My impression is that this is being dealt with piecemail by creating new versions of dozens of subcategories specific to an application. Is this what we want? --[[User:Tanstaafl|Tanstaafl]] 4:00AM, 16 January 2006 (PST)<br />
<br />
==Hot topic&mdash;the new front page==<br />
See [[Knowledge Base]] and [[Talk:Knowledge Base]].<br />
<br />
==New proposal&mdash;implementing "browse by UI feature" system for Firefox articles==<br />
See [[Firefox components]] and [[Talk:Firefox components]].<br />
<br />
==Question&mdash;how to use "SeaMonkey" in the kb from now?==<br />
With the SeaMonkey 1.0 release just around the corner, I've been wondering how we should adjust for the use of the "SeaMonkey" name in the kb. As it is now, the article-naming conventions and in-house style both specify that only "Mozilla Suite" is to be used. Since SeaMonkey has features not in the Suite, it seems like it would make sense to start referring to the proper product name when it's needed to differentiate it from the Suite; perhaps we could linkify "SeaMonkey" in such cases so that it leads back to the category page, where there could be a blurb about the two names being used in the kb. Thoughts? --[[User:Wintogreen|wintogreen]] 18:23, 4 January 2006 (UTC)<br />
:Maybe we could link to the [[Mozilla_Suite_:_FAQs_:_Status]] page if we needed to refer to SeaMonkey and mention somewhere that articles referring to "Mozilla Suite" may also apply to "SeaMonkey" and other unofficial Mozilla-based products. Correct me if I'm wrong but all "Mozilla Suite" articles should continue to apply only to the official Mozilla Suite 1.7.xx product. I figure a separate category should be set up for "SeaMonkey" just as there is a [[:Category:Nvu]]. [[User:Alice Wyman|Alice Wyman]] 16:35, 5 January 2006 (UTC)<br />
::In [[:Category:Preferences]] we're listing them both.--[[User:Np|Np]] 22:50, 5 January 2006 (UTC)<br />
:::I agree with Alice; it sounds like we should introduce a new category for Seamonkey. I would think that lots of the Mozilla Suite articles could also be placed in the new category for now (after putting a "this article was written for the Mozilla Suite but also applies to SeaMonkey" notice at the top of them). Sooner or later SeaMonkey will have progressed to the point that the Mozilla Suite articles will no longer apply. At this point, these articles should be taken out of the SeaMonkey category again, and new ones written purely for SeaMonkey. --[[User:Mozcerize|Mozcerize]] 11:31, 6 January 2006 (UTC)<br />
::::Well, hopefully it won't get too messy. I'm thinking I might make an article similar to [[Menu differences in Windows, Linux, and Mac]] for Thunderbird - Suite - SeaMonkey menu differences, so that instead of trying to stuff Suite/SeaMonkey menu sequences into TB articles I can just insert a link into the notice at the top that says "...written for TB but also applies to Suite/SeaMonkey (though some menu sequences may differ)". --[[User:Wintogreen|wintogreen]] 13:48, 8 January 2006 (UTC)<br />
:::::I agree with Wintogreen about the need for standard one-liner. I have no interest in spending time learning about Seamonkey or Mozilla Suite when writing a knowledge base article for Thunderbird, yet know I have to somehow mention them. --[[User:Tanstaafl|Tanstaafl]] 3:42AM, 16 January 2006 (PMT)<br />
<br />
::::::I've taken a stab at this with a new template -- [[Template:Tbsuite]], now in action [[Compacting folders|here]]. It lists both Mozilla Suite and SeaMonkey and links to the page Alice suggested. Some articles flagged like this will apply to both the Suite and SM, and some to SM only, but we can let the users of those respective apps worry about it from there.<br>As for creating SeaMonkey categories... what's to be gained by doing this instead of using the existing Mozilla Suite categories (or redirecting those to become SM categories, as I think can be done)? If SM features or menu sequences need to be differentiated from those for the Suite, that can be done easily enough within the article (like has been done for different TB versions in [[Multiple SMTP servers (Thunderbird)|this article]]). Considering that the Suite categories are a mess as is, with no one taking care of them, why double the mess by creating a parallel set of SM categories? --[[User:Wintogreen|wintogreen]] 17:00, 16 January 2006 (UTC)<br />
<br />
::::::: I see your linked text in the [[Template:Tbsuite]] is ''Mozilla Suite / SeaMonkey'' which might make someone think of them as the same product, renamed. The [[Mozilla_Suite_:_FAQs_:_Status | linked page]] says that "the Suite is no longer an official product" which is ambiguous. I was considering them as separate products when I suggested a separate category for SeaMonkey, with Mozilla Suite being the official product, especially since both products are available and Mozilla Suite is continuing to be updated, if only for security bug fixes. I noticed on the [[Category_talk:Preferences]] page containing guidelines for preference articles, the [[Category_talk:Preferences#Formatting | Formating section]] also referenced ''Mozilla Suite/SeaMonkey'' as a single product, while in preference artilces supposedly based on those guidelines, they are listed as separate products. See my comments under [[Knowledge_Base_changes#Article-writing_guidelines | Article-writing guidelines]] below. [[User:Alice Wyman|Alice Wyman]] 14:16, 17 January 2006 (UTC)<br />
<br />
:::::::: Hi Alice. What I've been thinking, since I made the trial template, is that the [[Mozilla_Suite_:_FAQs_:_Status | linked page]] should be like the [[Firefox]] and [[Thunderbird]] pages PLUS serve as a kind of disambiguation page&mdash;i.e., by summarizing the Suite/SeaMonkey connection and noting that a handful of articles claiming to apply to the Suite/SeaMonkey may really only apply to one of them, due to changes since the Suite development stopped. That page would have to be modified, or a different page used instead. Yes, they are separate products (or, one's a "product" and one's a "project"), and referring to them in a template as "Mozillla Suite/SeaMonkey" is not ideal. But as tanstaafl pointed out, we do need a practical, simple way of referring to "the Mozilla Suite and/or SeaMonkey" in TB articles. I'm open to other ideas. How about "SuiteMonkey"? --[[User:Wintogreen|wintogreen]] 16:53, 17 January 2006 (UTC)<br />
<br />
::::::::: Hi, wintogreen. I agree the [[Mozilla_Suite_:_FAQs_:_Status | linked page]] for the template should be modified, or better yet, create a new page explaining the Mozilla Suite and SeaMonkey commonalities and differences. In most cases, just a template will do, whatever you want to use as the linked text (I would go with "Mozilla Suite and SeaMonkey") . In new articles that apply to both products, I would probably stay with "Mozilla Suite" with a link to a "Mozilla Suite and SeaMonkey" template, and not refer "SeaMonkey" at all in the article unless I was referring to certain features that are only present in SeaMonkey 1.0 or later. The problem I see is inconsistency. Look at [[browser.bookmarks.file]] and [[browser.cache.disk.capacity]] under "UI". The first has "Mozilla Suite" and the second has "Mozilla Suite and SeaMonkey". By the way, I was editing below under [[Knowledge_Base_changes#Article-writing_guidelines | Article-writing guidelines]] before I saw your reply here. [[User:Alice Wyman|Alice Wyman]] 18:03, 17 January 2006 (UTC)<br />
<br />
:::::::::: I'd be more inclined to use "SeaMonkey" in an article if I know for sure that it applies to SeaMonkey and especially if I don't know if it also applies to Mozilla Suite (which will more and more be the case as time passes). --[[User:Wintogreen|wintogreen]] 19:55, 17 January 2006 (UTC)<br />
<br />
::::::::::: ''...if I don't know if it also applies to Mozilla Suite.....'' What, you don't plan on keeping both versions, for testing and such? ;-) In that case, if you didn't know for sure that a new article applied to both products, create the category "SeaMonkey" and place the new article there, with a reference that the article was written for SeaMonkey but may also apply to Mozilla Suite? [[User:Alice Wyman|Alice Wyman]] 21:27, 17 January 2006 (UTC)<br />
::::::::::::You wouldn't believe the number of new Thunderbird users who can't even get it straight whether the dedicated email client they're using is called Thunderbird, Firefox, Firebird or Mozilla. Wintogreens one-liner about Mozilla Suite / Seamonkey alerts somebody that its likely (but not 100% sure) the article also applies to those products and minimizes the amount of work the author does. If somebody ever confirms it applies then they have the option of adding the article to the Mozilla Suite and/or SeaMonkey category and/or stating something specific about the differences in support. I guess I'm arguing that the expense of avoiding inconsistency isn't worth it given all of the bigger fish to fry. --[[User:Tanstaafl|Tanstaafl]] 2:40AM, 18 January 2006 (PMT)<br />
<br />
::::::::::::: Update: since the above-mentioned <nowiki>{{Tbsuite}}</nowiki> template is now in use and linking to [[Mozilla Suite : FAQs : Status]], I tried to fill out that page to make it a bit more useful. That page doesn't have to be the permanent target for the template, of course; if someone wants to move the relevant content elsewhere and update the template link accordingly, feel free. --[[User:Wintogreen|wintogreen]] 19:40, 27 January 2006 (UTC)<br />
<br />
:::::::::::::: Nice work. The [[Mozilla Suite : FAQs : Status | page]] is a lot more useful now. I did some very minor editing and added a short blurb mentioning "SeaMonkey" at the top. [[User:Alice Wyman|Alice Wyman]] 20:47, 27 January 2006 (UTC)<br />
<br />
::::::::::::::: Thanks for your further edits to that page. The phrase you've inserted at the top&mdash;"Mozilla Suite code development and the SeaMonkey project"&mdash;would make a good name for the article. Or maybe just "Mozilla Suite development and the SeaMonkey project" or "Mozilla Suite development and SeaMonkey"? --[[User:Wintogreen|wintogreen]] 02:34, 28 January 2006 (UTC)<br />
<br />
:::::::::::::::: Those are all pretty long titles so I would go with the shortest, or even "Mozilla Suite status and SeaMonkey" or similar, whatever you decide, as long as the word "SeaMonkey" is in the title. Otherwise, I would change the name of the first section from ''Development status of the Mozilla Suite'' to "Mozilla Suite code development and the SeaMonkey project" so that the word "SeaMonkey" is more visible right at the beginning of the article. [[User:Alice Wyman|Alice Wyman]] 13:57, 28 January 2006 (UTC)<br />
<br />
::::::::::::::::: For now I've just changed the first header; appreciate the input and suggestions. --[[User:Wintogreen|wintogreen]] 16:30, 28 January 2006 (UTC)<br />
<br />
=== Specific questions re: "SeaMonkey" ===<br />
Now that the discussion has been raging for a while, I've decided to list up what seem to be some of the key issues regarding the use of "SeaMonkey" in the kb. With numbers, for your commenting convenience. --[[User:Wintogreen|wintogreen]] 20:22, 18 January 2006 (UTC)<br />
<br />
# In kb articles in general, should Mozilla Suite and SeaMonkey be ''treated'' as two distinct products or as one product (i.e., akin to earlier and later versions of the same product)?<br />
# If they are to be treated as two distinct products, should we normally refer to them using both product names ("Mozilla Suite and SeaMonkey")?<br />
# If we decide to normally use just one product name (either "Mozilla Suite" or "SeaMonkey") to refer to both, which name should we use?<br />
# Should any special guidelines apply to the [[:Category:Preferences|Preferences]] articles (different from those for the regular user-support articles)?<br />
# Should there be separate sets of categories for Mozilla Suite and SeaMonkey?<br />
<br />
<br />
Very brieflly, here are my own thoughts on the above. --[[User:Wintogreen|wintogreen]] 20:24, 18 January 2006 (UTC)<br />
# In general, as one product. I don't think kb users will be confused by this, and it will be easier for us editors as well.<br />
# No. Using both names all the time would be awkward (except perhaps in a simple template like [[Template:Tbsuite|this]]).<br />
# SeaMonkey. That will seem the obvious choice two years from now.<br />
# Not sure.<br />
# No. I can't see any benefit in doing this. <br />
------------------------------------------------<br />
I've added my thoughts below: [[User:Alice Wyman|Alice Wyman]] 21:16, 18 January 2006 (UTC)<br />
# In general, as two products, similar to the way Netscape 7.xx and Mozilla Suite are treated.<br />
# Either product name can be used with a note that it was written for one but may also apply to the other, or that it applies to both. If writing new articles for both, use both names only if necessary to differentiate and note any differences within the article as is done now for "Firefox 1.0.7" and "Firefox 1.5" differences. <br />
# ---<br />
# I see the question as whether the "de facto" preference article guidelines [[:Category_talk:Preferences | here]] should be formalized and made easier to find by new editors Check any of the [[:Category:Preferences]] articles that have been written already and you will see that they all follow the same format. When I wrote a new preference article it was immediately edited to add the "Has an effect in" section I omitted.<br />
# Yes. This is needed for new articles written for SeaMonkey 1.0 where the writer does not know if the content also applies to Mozilla Suite, or knows for sure that it doesn't.<br />
------------------------------------------------<br />
<br />
==New proposal&mdash;"Startup and performance" category==<br />
I'd appreciate some input on the title for this category, esp. as it would be best to choose a category name that works for all apps. Please add your comments at [[Talk:Rules/Categories#Some_new_categories]]. --[[User:Wintogreen|wintogreen]] 11:15, 5 January 2006 (UTC)<br />
:This proposal is dead as far as I'm concerned. The only question is whether "Startup and performance" would make a viable category name for any application. If not, then it'd be best to remove the links from the category tree at [[Talk:Rules/Categories]]. --[[User:Wintogreen|wintogreen]] 08:07, 17 January 2006 (UTC)<br />
<br />
<br />
==Article-writing guidelines==<br />
===(Also related to SeaMonkey references in the kb and making things less daunting to new editors)===<br />
The [[Category talk:Preferences]] page includes guidelines for writing preference articles. Should these guidelines (and possibly guidelines for other article categories) be formalized? Where would you want to place the guides in the kb so that people can find them? Here is part of what I wrote to [[User Talk:Unarmed | Unarmed on his Talk page]] ''It never occurred to me to look on a Talk page for article-writing guidelines (I would think that anything on a "Talk" page is "informal"). I'd suggest formalizing those "guidelines" for anyone wanting to write a new preferences page.'' <snip> ''I'm assuming you want people to follow a certain format in a category like Preferences since that's the impression I got from Np. If that's the case, you should link to an article explaining what you want followed in [[Rules]] or [[In-house style]]. I'm not sure where you would place an article like that but I would guess somewhere in [[:Category:MozillaZine_Knowledge_Base_organization]].'' [[Category_talk:Preferences#Moving_some_of_this_to_a_separate_page | I've also suggested]] that the discussion about formalizing those guidelines be moved here. <br />
Since the question about SeaMonkey references in the kb has also come up, the [[In-house style]] page should be amended to make clear whether Mozilla Suite and SeaMonkey should be referenced as the same product (e.g. "Mozilla Suite/SeaMonkey") or separate products ("Mozilla Suite and SeaMonkey") and under what circumstances. For example, [[Category_talk:Preferences#Formatting]] is using ''Mozilla Suite/SeaMonkey'' to refer to a single product, while in preference articles supposedly based on those guidelines, both are listed as separate products, as in the "UI" and "Has an effect in" sections of [[browser.bookmarks.file]] and [[browser.cache.disk.capacity]]. I would suggest only using "SeaMonkey" as a separate product name when referring to features not found in Mozilla Suite. (Is the "Has an effect in" subheading listing Netscape SeaMonkey Firebird and Phoenix even needed?) [[User:Alice Wyman|Alice Wyman]] 11:51, 17 January 2006 (UTC)<br />
:Um... you're assuming somebody knows whether it applies to either of those two applications when writing an article for another application. Thats not realistic, and just makes it more daunting to new editors. I know my first reaction to the change you propose would be I'd like to help out users of other applications but I don't need this grief, and only mention Thunderbird the next time I write a email article. Being slightly inaccurate is healthy in some circumstances. Especially when you consider the slow pace of updating existing articles. [[User:Tanstaafl|Tanstaafl]] 2:45AM, 18 January 2006 (PMT) <br />
:: What proposal? I did propose that the [[In-house style]] page should be amended to make clear whether Mozilla Suite and SeaMonkey should be referenced as the same product (e.g. "Mozilla Suite/SeaMonkey") or separate products ("Mozilla Suite and SeaMonkey") and under what circumstances. If you are responding to what I said immediately above, "I would suggest only using "SeaMonkey" as a separate product name when referring to features not found in Mozilla Suite."..... then, in that case, I was thinking about the "UI" and "Has an effect in" sections of preference articles, specifically [[browser.cache.disk.capacity]] and [[browser.bookmarks.file]] in the context of article-writing guidelines, when the same preference applies to both products. I also mentioned in the separate "SeaMonkey" discussion above that I would probably stick with "Mozilla Suite" in new articles if the features applied to both and not mention SeaMonkey at all if it wasn't necessary. In other words, no one should be forced to refer to SeaMonkey at all. On the other hand, maybe no one should be forced to refer to Moziila Suite either... is that what you're saying? I would agree with you, if someone is writing a new article and his only experience is with SeaMonkey, he should not reference Mozilla Suite or Thunderbirs at all, and the article should have a disclaimer that it was written for SeaMonkey, etc (another reason for a SeaMonkey category). [[User:Alice Wyman|Alice Wyman]] 17:57, 18 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Mozilla_Suite_:_FAQs_:_Status&diff=22295Mozilla Suite : FAQs : Status2006-01-28T16:17:52Z<p>Wintogreen: header change</p>
<hr />
<div>== Mozilla Suite code development and the SeaMonkey project ==<br />
<br />
The 1.7 release of the Mozilla Suite is the last major release as an official Mozilla Foundation product. It will be maintained with 1.7.xx version releases to fix known security problems or other critical issues but there will be no official Mozilla Suite 1.8 release. This will enable the foundation to devote its resources to the standalone Firefox and Thunderbird applications.<br />
<br />
Although official development has ceased, the Suite will continue to evolve as a community-led ''project'' and will receive substantial support from the Foundation. In particular, the development community will still use mozilla.org's webtools such as CVS, LXR and [[Bugzilla]], and foundation members have provided significant advice to the community on how to organise successful future releases of a Gecko-based application suite. The project will be "driven" by members of the community who will be responsible for maintaining code, dictating the release schedule and performing QA on the final releases. More information on the organisational structure that has developed to maintain the suite and manage future releases is on the [http://wiki.mozilla.org/SeaMonkey:Home_Page SeaMonkey homepage] of the [http://wiki.mozilla.org/ mozilla.org wiki]. <br />
<br />
Since this community-led project will not result in an official Mozilla Foundation product, it has been agreed that the name and version number of the next release must change. In particular it is not possible to use the "Mozilla" trademark on an unofficial product. The name of the next release will be "SeaMonkey 1.0" (Seamonkey is the longtime codename of the Mozilla Suite).<br />
<br />
== Differences between the Mozilla Suite and SeaMonkey ==<br />
<br />
Despite the name change, SeaMonkey 1.0 will feel very familiar to Mozilla Suite users, but it will incorporate numerous new features, UI improvements, and bugfixes. Some of these will be listed in the release notes, available through the [http://www.mozilla.org/projects/seamonkey/ SeaMonkey project page].<br />
<br />
<br />
''This section is a [[stub articles|stub]]. You can help MozillaZine Knowledge Base by expanding it.''<br />
<br />
=="Mozilla Suite" vs. "SeaMonkey" in Knowledge Base articles==<br />
<br />
Contributors to this Knowledge Base are in the process of [[Knowledge Base changes|trying to formulate a scheme]] for how best to refer to the Mozilla Suite and SeaMonkey in Knowledge Base articles and categorize the articles related to each. Until that scheme is worked out and eventually implemented, you may find one or both names used in different articles. For the time being, it is generally safe to assume that all references to "Mozilla Suite" also apply to "SeaMonkey".<br />
<br />
In some articles, especially those written for Thunderbird, there may be a note stating that the article "also applies to Mozilla Suite / SeaMonkey". This could mean that the article applies to both products (most likely) or perhaps only to SeaMonkey (e.g., due to new features in SeaMonkey that are lacking in the Mozilla Suite). Article writers often don't know the specific differences between Mozilla Suite and SeaMonkey and thus use the shorthand "Mozilla Suite / SeaMonkey" note to flag articles that might be of interest to Mozilla Suite and/or SeaMonkey users.<br />
<br />
==See also==<br />
* [[Summary of Mozilla products]]<br />
* [[Mozilla Suite]] articles in this Knowledge Base.<br />
<br />
==External links==<br />
* [http://www.mozilla.org/seamonkey-transition.html Transition plan] on the decision to not release a version 1.8 of the Mozilla Suite<br />
* [http://wiki.mozilla.org/SeaMonkey:Home_Page SeaMonkey homepage] in the mozilla.org wiki<br />
* [http://weblogs.mozillazine.org/seamonkey/ SeaMonkey weblog] with updates on development progress<br />
* [http://www.mozilla.org/projects/seamonkey/ SeaMonkey product page] where you can download SeaMonkey and access the release notes<br />
* [http://www.mozilla.org/products/mozilla1.x/ Mozilla Suite product page] where you can download the latest 1.7.x version of Mozilla Suite<br />
<br />
[[Category:Mozilla Suite]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Synchronizing_mail_on_two_computers&diff=22294Synchronizing mail on two computers2006-01-28T16:14:04Z<p>Wintogreen: link be gone</p>
<hr />
<div>Trying to sychronize your Thunderbird mail on two different computers? Below are some possible solutions.<br />
<br />
* If possible, switch to an [[IMAP]] account. All your mail (incoming, outgoing, drafts, etc.) will be stored on the server and be accessible from multiple computers. Many IMAP providers also let you configure your account (server-side) to fetch mail from separate POP accounts. You could also use the [http://www.gargan.org/extensions/synckolab.html Synch Kolab] extension to synchronize your address books.<br />
<br />
* Try [http://synchingthunder.sourceforge.net Synching Thunder], which was designed to synchronize Thunderbird mail stored on different computers. Make sure to read the installation notes and other documentation carefully.<br />
<br />
* Install and run Thunderbird [[Running from a USB drive (Thunderbird) | from a flash drive or other portable USB device]].<br />
<br />
* Install Thunderbird separately on each computer but store your [[profile folder | profile]] on a portable USB device or on a network file share. To launch Thunderbird with that profile, use the [[Running from a USB drive (Thunderbird) |''-profile "path"'']] command line argument.<br />
<br />
* Set Thunderbird to leave incoming mail on the server (for a long enough period of time) so that the same messages can be downloaded on both computers. One way to do this: for the ''secondary'' computer only (such as a laptop), go to "[[Menu differences in Windows, Linux, and Mac|Tools -> Account Settings]] -> [account name] Server Settings", check the box for "Leave messages on server", and then set "Tools -> Account Settings -> Copies & Folders -> Bcc these email addresses" to automatically send yourself a copy of any messages you send. On your ''primary'' computer write a [[Filters (Thunderbird)| message filter]] that moves those messages to your Sent folder and marks them as read. Note: in some cases leaving mail on the server may cause the same messages to be [[Duplicate messages received | downloaded repeatedly]] on the same machine. <br />
<br />
* Use a script or batch file like [http://gemal.dk/mozilla/profilesync.html 4NT] to synchronize the files in two profiles. This method is most likely to cause problems, especially if you forget to synchronize before doing something that modifies the profile.<br />
<br />
==See also==<br />
*[[PalmSync (Thunderbird)|PalmSync]]<br />
*[[Roaming profile]]<br />
*[[Synchronizing Windows based PDAs]]<br />
<br />
[[Category:Mail (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Synchronizing_multiple_machines&diff=22293Talk:Synchronizing multiple machines2006-01-28T16:13:31Z<p>Wintogreen: reply</p>
<hr />
<div>This seems rather redundant with [[Synchronizing mail on two computers (Thunderbird)]]. Why not merge them into a single article? --[[User:Wintogreen|wintogreen]] 05:34, 19 January 2006 (UTC)<br />
<br />
I have no problem with the two articles being merged. I'm not quite sure how we got into this situation since I don't remember seeing the other one at the time though there are obvious similarities. It doesn't matter. I had used "multiple machines" in the title because of several threads where somebody was trying to synch more than two PCs plus a PDA. Its also not clear to me why the merged article has to be explicitly Thunderbird only since most (possibly all) of the methods should also work for Mozilla Suite/SeaMonkey. I suspect even SynchingThunder works with Mozilla Suite/SeaMonkey since its a standalone program that doesn't appear to be Thunderbird aware, it just wants you to browse a profile and click on the mbox files. I suggest we live with the current name but you add (to the existing merged article) the tag you created that states a article was written for Thunderbird but might also apply to Mozilla Suite/Seamonkey. <br />
<br />
Everything in Ed Mullen's article seems to be in the knowledge base article. I suggest we drop that external link. <br />
[[User:Tanstaafl|Tanstaafl]] 12:06, 28 January 2006 (UTC)<br />
<br />
:SynchingThunder might well work with the Suite, but I see no indication that Sync Kolab does, and as far as I know the ''-profile "path"'' command argument works with neither Mozilla Suite nor SeaMonkey (it just brings up the profile manager instead of launching with the specified profile). Flagging this as a Suite/SeaMonkey article would also require flagging those parts that are TB-specific, which just makes the article messier. Under the circumstances I think it'd be better to have a separate Suite/SM article. --[[User:Wintogreen|wintogreen]] 16:13, 28 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Thunderbird_:_FAQs&diff=22284Talk:Thunderbird : FAQs2006-01-28T03:01:49Z<p>Wintogreen: /* so, how does one install an extension? */ reply</p>
<hr />
<div>== This page looks huge ==<br />
<br />
There is too much on the page. I've tried reorganzing it (awhile ago), removing unneeded text (by removing redundancies and making the wording more succinct), and emphasizing the section headers (today).<br />
<br />
What about breaking it into two pages: mail and everything else?<br />
<br />
guanxi 13:33, 08 Feb 2005 (Tue)<br />
<br />
-----<br />
<br />
Also, I'm not sure the all-link format looks better than plain text + link. For example, wouldn't this look better?<br />
<br />
====E-mail Account Setup====<br />
* [[Thunderbird : FAQs : Getting Started | Basic e-mail account configuration]] (a guide for beginners)<br />
* [[Using webmail with your email client | Use webmail]], including Gmail, Hotmail, MSN, AOL, or Yahoo! Mail<br />
* [[Thunderbird : FAQs : Global Inbox | Global Inbox]] - One Inbox for multiple e-mail accounts<br />
* [[Thunderbird : FAQs : Multiple Identities | Multiple identities]] (return addresses) for one e-mail account<br />
* [[Thunderbird : FAQs : Multiple SMTP Servers | Multiple SMTP]] (outgoing mail) servers or accounts<br />
* [[Thunderbird : FAQs : SMTP Authentication | SMTP (outgoing mail) authentication]]<br />
* [[Thunderbird : FAQs : Migration | Import e-mail & settings]] from other programs (Mozilla, Netscape, Outlook Express, Eudora, AOL, etc.)<br />
<br />
<br />
If I don't hear back, I'll change it.<br />
<br />
guanxi 13:54, 08 Feb 2005 (Tue)<br />
<br />
== Style cleanup & article renaming==<br />
Every article linked on this page has been cleaned up per [[In-House Style]], as of today. --[[User:Wintogreen|Wintogreen]] 12:04, 5 Apr 2005 (PDT)<br />
<br />
Re: article renaming, see [[Talk:Thunderbird : FAQs/Articles to rename]]. --wintogreen<br />
<br />
== so, how does one install an extension? ==<br />
<br />
howdy y'all,<br />
<br />
shouldn't there be some mention of how to install an extension? yes, this ...<br />
http://kb.mozillazine.org/Extensions_%28Thunderbird%29<br />
<br />
.. covers it. but one would think that it would be linked to the main faq. is there a reason not to have it there?<br />
<br />
take care,<br />
lee<br />
:Well, the main FAQ isn't really the main FAQ anymore. This page isn't being actively updated now that we're using a [[:Category:Thunderbird|category-based]] organizational scheme (where the links for info on installing extensions now appear in both the "Extensions" and "Installation and update" categories for TB). Of course, if anyone wants to keep adding links to this page, it's perfectly fine to do so. --[[User:Wintogreen|wintogreen]] 03:01, 28 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Talk:Extensions_-_Thunderbird&diff=22282Talk:Extensions - Thunderbird2006-01-28T02:49:23Z<p>Wintogreen: reply</p>
<hr />
<div>howdy y'all,<br />
<br />
why does this page show up in kb search with this ...<br />
http://kb.mozillazine.org/Special:Search?search=thunderbird+extensions&go=Go<br />
<br />
... but NOT with this one ...<br />
http://kb.mozillazine.org/Special:Search?search=thunderbird+extension&go=Go<br />
<br />
note that the plural of "extension" is the only diff. shouldn't the singular be included in the plural?<br />
<br />
take care,<br />
lee<br />
<br />
:It does show up in the latter search, only not near the top (more like #59). Intelligent search is not one of the wiki's stronger points, unfortunately. --[[User:Wintogreen|wintogreen]] 02:49, 28 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Knowledge_Base_changes&diff=22281Knowledge Base changes2006-01-28T02:34:32Z<p>Wintogreen: /* Question&mdash;how to use "SeaMonkey" in the kb from now? */</p>
<hr />
<div>{{org}}<br />
==Temporary introduction==<br />
This page has been created for several reasons.<br />
<br />
*It would be nice to have a place where new editors can introduce themselves and meet existing editors.<br />
*It would be good to allow new editors to safely propose content changes (minor or major) prior to implementing them.<br />
*It would be good to have a central location to discuss the style, content and organisation of this Knowledge Base. (Some of the ideas in [[Talk:Knowledge Base]] can be migrated here, leaving that page solely for discussion of the front page article itself.<br />
*This page is an attempt to address recent incidents that have occured on the KB where some groups of editors have been unaware of major changes being made by other groups of editors.<br />
<br />
We intend to place a link to this page in the "welcome to new editors" paragraphs found on the front page and from the other "entrance" pages such as [[Firefox]] and [[Thunderbird]] if it is deemed useful.<br />
<br />
We anticipate this page being the primary place to announce new suggestions. Please visit it regularly!<br />
<br />
==Welcome to new editors==<br />
Hello! Great to have you here. Please add a comment here :-)<br />
<br />
* Hello Knowledge Base! FJ reporting to duty! *bows at all* [[User:FatJohn|FatJohn]] 11:30, 3 January 2006 (UTC)<br />
<br />
==Hot topic&mdash;Making things less daunting for new editors==<br />
Several new editors (or potential editors) have felt a bit daunted by the [[rules]] for contributing. I think this is a shame; we want their contributions! (The rules are fairly comprehensive and are written formally; this is for the benefit of regular contributors. But it was never anyone's intention to discourage new editors.) I have added an introduction to the [[rules]] page, which states that they don't need to read everthing thoroughly. This could be controversial; please state your view here! Should we include that sentiment in other places too? And should we put a sticky in the forums which tries to bring new editors to the KB? --[[User:Mozcerize|Mozcerize]] 13:10, 8 January 2006 (UTC)<br />
:Looks good; you have a knack for writing these welcome intros. Where else would that sentiment be included? Instead of a forum sticky, I'd just use a regular thread in the General forums; the regulars will see it. A few suggestions: (1) The "Please don't be offended..." sentence can come out or be merged into the similar point in the "Editing courtesy" section. (2) The "Avoid superfluous information" section could go into In-house style. (3) The "Test editing pages" section could come to the very top, above "Editing courtesy", as a way to invite people to take the plunge into editing. (4) "Talking to authority" should come out; those links are all available in kb Organization category and aren't rules in the first place. (5) [[Rules/Templates]] should be renamed because those templates aren't rules; they're editing shortcuts and should be presented as such. --[[User:Wintogreen|wintogreen]] 14:36, 8 January 2006 (UTC)<br />
::I'll look into these suggestions soon! --[[User:Mozcerize|Mozcerize]] 17:50, 10 January 2006 (UTC)<br />
<br />
I suggest the rules be modified to state that you shouldn't post a notice on a page unless it adds value to the reader. For example, posting a notice stating that the name of the knowledge base page is in error (when its actually due to a limitation of the wiki software) just causes confusion and annoys the person who wrote the article. The reader doesn't care that we're using Wiki software. Note that I'm not arguing against a notice that an article needs rewriting. The reason I'm mentioning this in this section is because behavior that seems perfectly appropiate to somebody steeped in the wiki culture can be upsetting to a new editor who has never had to deal with collaborative writing with strangers.<br />
<br />
I'm not a wiki person. It was easy to pick up what I needed to know to edit knowledge base articles before we switched to categories. Its more difficult now. An example - I need to create a new category. I read Rules/Categories and it wasn't clear to me how to create a new category, though I understood how to make a category a subcategory because that didn't require any background knowledge. Please think about the barrier to entry you're accidentally creating by assuming a new editor has a wiki background. <br />
<br />
I don't think creating a thread will help attract new editors. I suggest you consider converting MozillaZine_Knowledge_Base:Formatting into a short primer on what you need to know to be an editor. The current article does a good job of covering what you need to know about formatting. But it <br />
doesn't cover other common tasks such as how you create a new article or how to categorize it. Yes, there are links to wiki documentation where you can find that but its rather overwhelming for somebody who may know a little HTML or bbcode and is not used to reading rules, in-house style guides, naming conventions etc. while learning yet another formatting syntax. Think of all that we're implying a person should read before doing something small such as update an existing article for a new version. Especially since they really don't need to deal with most of those topics until they create a new article, if they make an attempt to mimic what they see in the article they're editing. I think its telling that some of our most prolific forum posters such as Daifne, SKopischke, GordMcFee and Mr. Liu have never touched the knowledge base as far as I can tell. The current approach seems designed to tell you everything that you need to know to do it right in order to minimize cleanup by other editors. I think we should increase the risk that we'll have to cleanup after a new editor for a while if that makes it easier to lower the barrier to entry (whether its real or perceived).<br />
<br />
I'm suggesting that we make it easy for them to get started by letting them get started using just the primer, let them learn more of the conventions/customs (documented in the rules, guides etc.) later on as they tackle bigger tasks, and try to avoid giving them the impression they need to learn everything before they can do anything. Once thats in place its also easier for somebody to encourage somebody to contribute. <br />
<br />
It might also help if one or two names (perhaps Wintogreen?) were mentioned in the primer as volunteers that new editors are encouraged to contact via private messages for advice if they need it. --[[User:Tanstaafl | Tanstaafl]] 3:30 AM January 16, 2006 (PMT)<br />
<br />
<br />
I took the liberty of expanding the [[MozillaZine Knowledge Base:About|About]] page, in particular the "Contributing to the KB" section. If someone could please review it and revise where you think it can be improved, that'd be great. Note that I also added a "Need help with the wiki?" section at the end of the [[Help wanted]] page. That's my way of saying I don't want to be a designated go-to guy. ;-) --[[User:Wintogreen|wintogreen]] 19:14, 19 January 2006 (UTC)<br />
<br />
==Hot topic&mdash;replacing the FAQs and Issues pages with category navigation==<br />
Discussion of this proposal can be found on [[Talk:Rules/Categories]]). Some editors were not aware of this discussion (see [[Talk:Issues with Firefox]] and [[Talk:Rules/Categories#Flattening the Thunderbird categories]]). This was the main motivation for creating this page.<br />
<br />
To summarize the situation so far:<br />
<br />
Part of the motivation for implementing categories was to avoid the following situation which occurred with the original FAQs, Issues and Tips pages: article links had to be maintained manually; some articles appeared on more than one page; some articles didn't appear on any page. The result was that people had to look at all three pages to makes sure they didn't miss anything, and then perform a search as well. With categories, the danger that an article was never linked to from anywhere was removed, since category automatically list the articles. There was no opposition to removing the Tips pages.<br />
<br />
The suggestion to temove the FAQs and Issues pages was more controversial. Indeed, the problem with relying solely on category listings is that ''logical order'' is lost. The initial solution proposed was to use the editable part at the top of the category pages to recreate some logical order by factoring in parts of the FAQs and Issues pages.<br />
<br />
:My current opinion on this is that the FAQ and Issues pages should be kept, because they contain more info that could sensibly be placed in the category pages. However, I do think that they should both contain prominant links to the category pages, notifying the reader that there is more info on the KB than the selection of articles advertised on the FAQ and Issues pages. Indeed, I would suggest renaming "Issues " to "Common Issues with Firefox" to emphasise the fact that the Issues page is just a selection. --[[User:Mozcerize|Mozcerize]] 15:00, 2 January 2006 (UTC)<br />
<br />
:: First, thanks for the new discussion area and for the invitation to add comments. I've already added some comments to the [[Talk:Issues with Firefox]] page, back when it was first removed. I never did see the justification for removing either page, even if they are no longer linked from the front page. (I took it upon myself to restore them... I'm sorry it I stepped on anyone's toes but I was totally unaware of any discussion going on or a decision to remove the two pages. I strongly believe that both pages should be kept as they're a very handy way to organize and locate information, especially the FAQs page, which is unique in that the collection of links isn't duplicated anywhere else, alphabetically or not. Both pages are good places to include links to forum topics, release notes or other external links when there is no KB article covering the topic, plus the link descriptions give much more information than a simple title page link. I'm willing to help keep both pages organized and updated since I refer to them both so often. As far as the [[Issues with Firefox]] page, I've already pointed out in the intro that, "A link to an alphabetized list of current articles in the Category, Issues (Firefox) can be found at the end of this article." It might be a good idea to eliminate some of the less common issues on the page, such as the entire "Versions older than 1.0" section, and to emphasize that the page is a collection of "Common Firefox Issues" and is not exhaustive. I don't see the need for a new name but if someone else whats to rename the page "Common Firefox Issues" or similar, that's fine with me. [[User:Alice Wyman|Alice Wyman]] 20:47, 2 January 2006 (UTC)<br />
<br />
:::''"I'm sorry it I stepped on anyone's toes&hellip;."'' Not at all. Thanks for the points you've raised. The links to the forums and other offsite pages are indeed important. I was weighing up the idea of creating KB articles which act as wrappers for offsite links, that is, they have a useful title but their content is just a link. Ultimately, it would be good to have the info that they point to actually transferred to the article. (Anybody got a free week? ;-) I don't claim that this is an urgent task, but it would be good to have the offsite info represented somehow in the category listings. --[[User:Mozcerize|Mozcerize]] 11:25, 4 January 2006 (UTC)<br />
::::I made some changes to both the [[Firefox FAQs]] and [[Issues with Firefox]] pages today and made a note of this discussion on the Talk pages for each article. [[User:Alice Wyman|Alice Wyman]] 16:40, 7 January 2006 (UTC)<br />
:::::That's great; thanks! --[[User:Mozcerize|Mozcerize]] 12:15, 8 January 2006 (UTC)<br />
<br />
One of the current problems is that some of the categories mingle articles written for all of the products, even though you may have navigated there by selecting articles for one product. Somebody looking for information on Thunderbird privacy and security for example shouldn't see stuff such as Disabling autocomplete (Firefox), Mozilla Suite : FAQs : Mozilla Security or Parental controls. Ditto for navigating to Configuration::Preferences for Thunderbird and finding dozens of articles on preferences that Thunderbird doesn't support. I suggest we create a strategy for how to deal with this before creating a SeaMonkey category, which will just make it worse. My impression is that this is being dealt with piecemail by creating new versions of dozens of subcategories specific to an application. Is this what we want? --[[User:Tanstaafl|Tanstaafl]] 4:00AM, 16 January 2006 (PST)<br />
<br />
==Hot topic&mdash;the new front page==<br />
See [[Knowledge Base]] and [[Talk:Knowledge Base]].<br />
<br />
==New proposal&mdash;implementing "browse by UI feature" system for Firefox articles==<br />
See [[Firefox components]] and [[Talk:Firefox components]].<br />
<br />
==Question&mdash;how to use "SeaMonkey" in the kb from now?==<br />
With the SeaMonkey 1.0 release just around the corner, I've been wondering how we should adjust for the use of the "SeaMonkey" name in the kb. As it is now, the article-naming conventions and in-house style both specify that only "Mozilla Suite" is to be used. Since SeaMonkey has features not in the Suite, it seems like it would make sense to start referring to the proper product name when it's needed to differentiate it from the Suite; perhaps we could linkify "SeaMonkey" in such cases so that it leads back to the category page, where there could be a blurb about the two names being used in the kb. Thoughts? --[[User:Wintogreen|wintogreen]] 18:23, 4 January 2006 (UTC)<br />
:Maybe we could link to the [[Mozilla_Suite_:_FAQs_:_Status]] page if we needed to refer to SeaMonkey and mention somewhere that articles referring to "Mozilla Suite" may also apply to "SeaMonkey" and other unofficial Mozilla-based products. Correct me if I'm wrong but all "Mozilla Suite" articles should continue to apply only to the official Mozilla Suite 1.7.xx product. I figure a separate category should be set up for "SeaMonkey" just as there is a [[:Category:Nvu]]. [[User:Alice Wyman|Alice Wyman]] 16:35, 5 January 2006 (UTC)<br />
::In [[:Category:Preferences]] we're listing them both.--[[User:Np|Np]] 22:50, 5 January 2006 (UTC)<br />
:::I agree with Alice; it sounds like we should introduce a new category for Seamonkey. I would think that lots of the Mozilla Suite articles could also be placed in the new category for now (after putting a "this article was written for the Mozilla Suite but also applies to SeaMonkey" notice at the top of them). Sooner or later SeaMonkey will have progressed to the point that the Mozilla Suite articles will no longer apply. At this point, these articles should be taken out of the SeaMonkey category again, and new ones written purely for SeaMonkey. --[[User:Mozcerize|Mozcerize]] 11:31, 6 January 2006 (UTC)<br />
::::Well, hopefully it won't get too messy. I'm thinking I might make an article similar to [[Menu differences in Windows, Linux, and Mac]] for Thunderbird - Suite - SeaMonkey menu differences, so that instead of trying to stuff Suite/SeaMonkey menu sequences into TB articles I can just insert a link into the notice at the top that says "...written for TB but also applies to Suite/SeaMonkey (though some menu sequences may differ)". --[[User:Wintogreen|wintogreen]] 13:48, 8 January 2006 (UTC)<br />
:::::I agree with Wintogreen about the need for standard one-liner. I have no interest in spending time learning about Seamonkey or Mozilla Suite when writing a knowledge base article for Thunderbird, yet know I have to somehow mention them. --[[User:Tanstaafl|Tanstaafl]] 3:42AM, 16 January 2006 (PMT)<br />
<br />
::::::I've taken a stab at this with a new template -- [[Template:Tbsuite]], now in action [[Compacting folders|here]]. It lists both Mozilla Suite and SeaMonkey and links to the page Alice suggested. Some articles flagged like this will apply to both the Suite and SM, and some to SM only, but we can let the users of those respective apps worry about it from there.<br>As for creating SeaMonkey categories... what's to be gained by doing this instead of using the existing Mozilla Suite categories (or redirecting those to become SM categories, as I think can be done)? If SM features or menu sequences need to be differentiated from those for the Suite, that can be done easily enough within the article (like has been done for different TB versions in [[Multiple SMTP servers (Thunderbird)|this article]]). Considering that the Suite categories are a mess as is, with no one taking care of them, why double the mess by creating a parallel set of SM categories? --[[User:Wintogreen|wintogreen]] 17:00, 16 January 2006 (UTC)<br />
<br />
::::::: I see your linked text in the [[Template:Tbsuite]] is ''Mozilla Suite / SeaMonkey'' which might make someone think of them as the same product, renamed. The [[Mozilla_Suite_:_FAQs_:_Status | linked page]] says that "the Suite is no longer an official product" which is ambiguous. I was considering them as separate products when I suggested a separate category for SeaMonkey, with Mozilla Suite being the official product, especially since both products are available and Mozilla Suite is continuing to be updated, if only for security bug fixes. I noticed on the [[Category_talk:Preferences]] page containing guidelines for preference articles, the [[Category_talk:Preferences#Formatting | Formating section]] also referenced ''Mozilla Suite/SeaMonkey'' as a single product, while in preference artilces supposedly based on those guidelines, they are listed as separate products. See my comments under [[Knowledge_Base_changes#Article-writing_guidelines | Article-writing guidelines]] below. [[User:Alice Wyman|Alice Wyman]] 14:16, 17 January 2006 (UTC)<br />
<br />
:::::::: Hi Alice. What I've been thinking, since I made the trial template, is that the [[Mozilla_Suite_:_FAQs_:_Status | linked page]] should be like the [[Firefox]] and [[Thunderbird]] pages PLUS serve as a kind of disambiguation page&mdash;i.e., by summarizing the Suite/SeaMonkey connection and noting that a handful of articles claiming to apply to the Suite/SeaMonkey may really only apply to one of them, due to changes since the Suite development stopped. That page would have to be modified, or a different page used instead. Yes, they are separate products (or, one's a "product" and one's a "project"), and referring to them in a template as "Mozillla Suite/SeaMonkey" is not ideal. But as tanstaafl pointed out, we do need a practical, simple way of referring to "the Mozilla Suite and/or SeaMonkey" in TB articles. I'm open to other ideas. How about "SuiteMonkey"? --[[User:Wintogreen|wintogreen]] 16:53, 17 January 2006 (UTC)<br />
<br />
::::::::: Hi, wintogreen. I agree the [[Mozilla_Suite_:_FAQs_:_Status | linked page]] for the template should be modified, or better yet, create a new page explaining the Mozilla Suite and SeaMonkey commonalities and differences. In most cases, just a template will do, whatever you want to use as the linked text (I would go with "Mozilla Suite and SeaMonkey") . In new articles that apply to both products, I would probably stay with "Mozilla Suite" with a link to a "Mozilla Suite and SeaMonkey" template, and not refer "SeaMonkey" at all in the article unless I was referring to certain features that are only present in SeaMonkey 1.0 or later. The problem I see is inconsistency. Look at [[browser.bookmarks.file]] and [[browser.cache.disk.capacity]] under "UI". The first has "Mozilla Suite" and the second has "Mozilla Suite and SeaMonkey". By the way, I was editing below under [[Knowledge_Base_changes#Article-writing_guidelines | Article-writing guidelines]] before I saw your reply here. [[User:Alice Wyman|Alice Wyman]] 18:03, 17 January 2006 (UTC)<br />
<br />
:::::::::: I'd be more inclined to use "SeaMonkey" in an article if I know for sure that it applies to SeaMonkey and especially if I don't know if it also applies to Mozilla Suite (which will more and more be the case as time passes). --[[User:Wintogreen|wintogreen]] 19:55, 17 January 2006 (UTC)<br />
<br />
::::::::::: ''...if I don't know if it also applies to Mozilla Suite.....'' What, you don't plan on keeping both versions, for testing and such? ;-) In that case, if you didn't know for sure that a new article applied to both products, create the category "SeaMonkey" and place the new article there, with a reference that the article was written for SeaMonkey but may also apply to Mozilla Suite? [[User:Alice Wyman|Alice Wyman]] 21:27, 17 January 2006 (UTC)<br />
::::::::::::You wouldn't believe the number of new Thunderbird users who can't even get it straight whether the dedicated email client they're using is called Thunderbird, Firefox, Firebird or Mozilla. Wintogreens one-liner about Mozilla Suite / Seamonkey alerts somebody that its likely (but not 100% sure) the article also applies to those products and minimizes the amount of work the author does. If somebody ever confirms it applies then they have the option of adding the article to the Mozilla Suite and/or SeaMonkey category and/or stating something specific about the differences in support. I guess I'm arguing that the expense of avoiding inconsistency isn't worth it given all of the bigger fish to fry. --[[User:Tanstaafl|Tanstaafl]] 2:40AM, 18 January 2006 (PMT)<br />
<br />
::::::::::::: Update: since the above-mentioned <nowiki>{{Tbsuite}}</nowiki> template is now in use and linking to [[Mozilla Suite : FAQs : Status]], I tried to fill out that page to make it a bit more useful. That page doesn't have to be the permanent target for the template, of course; if someone wants to move the relevant content elsewhere and update the template link accordingly, feel free. --[[User:Wintogreen|wintogreen]] 19:40, 27 January 2006 (UTC)<br />
<br />
:::::::::::::: Nice work. The [[Mozilla Suite : FAQs : Status | page]] is a lot more useful now. I did some very minor editing and added a short blurb mentioning "SeaMonkey" at the top. [[User:Alice Wyman|Alice Wyman]] 20:47, 27 January 2006 (UTC)<br />
<br />
::::::::::::::: Thanks for your further edits to that page. The phrase you've inserted at the top&mdash;"Mozilla Suite code development and the SeaMonkey project"&mdash;would make a good name for the article. Or maybe just "Mozilla Suite development and the SeaMonkey project" or "Mozilla Suite development and SeaMonkey"? --[[User:Wintogreen|wintogreen]] 02:34, 28 January 2006 (UTC)<br />
<br />
=== Specific questions re: "SeaMonkey" ===<br />
Now that the discussion has been raging for a while, I've decided to list up what seem to be some of the key issues regarding the use of "SeaMonkey" in the kb. With numbers, for your commenting convenience. --[[User:Wintogreen|wintogreen]] 20:22, 18 January 2006 (UTC)<br />
<br />
# In kb articles in general, should Mozilla Suite and SeaMonkey be ''treated'' as two distinct products or as one product (i.e., akin to earlier and later versions of the same product)?<br />
# If they are to be treated as two distinct products, should we normally refer to them using both product names ("Mozilla Suite and SeaMonkey")?<br />
# If we decide to normally use just one product name (either "Mozilla Suite" or "SeaMonkey") to refer to both, which name should we use?<br />
# Should any special guidelines apply to the [[:Category:Preferences|Preferences]] articles (different from those for the regular user-support articles)?<br />
# Should there be separate sets of categories for Mozilla Suite and SeaMonkey?<br />
<br />
<br />
Very brieflly, here are my own thoughts on the above. --[[User:Wintogreen|wintogreen]] 20:24, 18 January 2006 (UTC)<br />
# In general, as one product. I don't think kb users will be confused by this, and it will be easier for us editors as well.<br />
# No. Using both names all the time would be awkward (except perhaps in a simple template like [[Template:Tbsuite|this]]).<br />
# SeaMonkey. That will seem the obvious choice two years from now.<br />
# Not sure.<br />
# No. I can't see any benefit in doing this. <br />
------------------------------------------------<br />
I've added my thoughts below: [[User:Alice Wyman|Alice Wyman]] 21:16, 18 January 2006 (UTC)<br />
# In general, as two products, similar to the way Netscape 7.xx and Mozilla Suite are treated.<br />
# Either product name can be used with a note that it was written for one but may also apply to the other, or that it applies to both. If writing new articles for both, use both names only if necessary to differentiate and note any differences within the article as is done now for "Firefox 1.0.7" and "Firefox 1.5" differences. <br />
# ---<br />
# I see the question as whether the "de facto" preference article guidelines [[:Category_talk:Preferences | here]] should be formalized and made easier to find by new editors Check any of the [[:Category:Preferences]] articles that have been written already and you will see that they all follow the same format. When I wrote a new preference article it was immediately edited to add the "Has an effect in" section I omitted.<br />
# Yes. This is needed for new articles written for SeaMonkey 1.0 where the writer does not know if the content also applies to Mozilla Suite, or knows for sure that it doesn't.<br />
------------------------------------------------<br />
<br />
==New proposal&mdash;"Startup and performance" category==<br />
I'd appreciate some input on the title for this category, esp. as it would be best to choose a category name that works for all apps. Please add your comments at [[Talk:Rules/Categories#Some_new_categories]]. --[[User:Wintogreen|wintogreen]] 11:15, 5 January 2006 (UTC)<br />
:This proposal is dead as far as I'm concerned. The only question is whether "Startup and performance" would make a viable category name for any application. If not, then it'd be best to remove the links from the category tree at [[Talk:Rules/Categories]]. --[[User:Wintogreen|wintogreen]] 08:07, 17 January 2006 (UTC)<br />
<br />
<br />
==Article-writing guidelines==<br />
===(Also related to SeaMonkey references in the kb and making things less daunting to new editors)===<br />
The [[Category talk:Preferences]] page includes guidelines for writing preference articles. Should these guidelines (and possibly guidelines for other article categories) be formalized? Where would you want to place the guides in the kb so that people can find them? Here is part of what I wrote to [[User Talk:Unarmed | Unarmed on his Talk page]] ''It never occurred to me to look on a Talk page for article-writing guidelines (I would think that anything on a "Talk" page is "informal"). I'd suggest formalizing those "guidelines" for anyone wanting to write a new preferences page.'' <snip> ''I'm assuming you want people to follow a certain format in a category like Preferences since that's the impression I got from Np. If that's the case, you should link to an article explaining what you want followed in [[Rules]] or [[In-house style]]. I'm not sure where you would place an article like that but I would guess somewhere in [[:Category:MozillaZine_Knowledge_Base_organization]].'' [[Category_talk:Preferences#Moving_some_of_this_to_a_separate_page | I've also suggested]] that the discussion about formalizing those guidelines be moved here. <br />
Since the question about SeaMonkey references in the kb has also come up, the [[In-house style]] page should be amended to make clear whether Mozilla Suite and SeaMonkey should be referenced as the same product (e.g. "Mozilla Suite/SeaMonkey") or separate products ("Mozilla Suite and SeaMonkey") and under what circumstances. For example, [[Category_talk:Preferences#Formatting]] is using ''Mozilla Suite/SeaMonkey'' to refer to a single product, while in preference articles supposedly based on those guidelines, both are listed as separate products, as in the "UI" and "Has an effect in" sections of [[browser.bookmarks.file]] and [[browser.cache.disk.capacity]]. I would suggest only using "SeaMonkey" as a separate product name when referring to features not found in Mozilla Suite. (Is the "Has an effect in" subheading listing Netscape SeaMonkey Firebird and Phoenix even needed?) [[User:Alice Wyman|Alice Wyman]] 11:51, 17 January 2006 (UTC)<br />
:Um... you're assuming somebody knows whether it applies to either of those two applications when writing an article for another application. Thats not realistic, and just makes it more daunting to new editors. I know my first reaction to the change you propose would be I'd like to help out users of other applications but I don't need this grief, and only mention Thunderbird the next time I write a email article. Being slightly inaccurate is healthy in some circumstances. Especially when you consider the slow pace of updating existing articles. [[User:Tanstaafl|Tanstaafl]] 2:45AM, 18 January 2006 (PMT) <br />
:: What proposal? I did propose that the [[In-house style]] page should be amended to make clear whether Mozilla Suite and SeaMonkey should be referenced as the same product (e.g. "Mozilla Suite/SeaMonkey") or separate products ("Mozilla Suite and SeaMonkey") and under what circumstances. If you are responding to what I said immediately above, "I would suggest only using "SeaMonkey" as a separate product name when referring to features not found in Mozilla Suite."..... then, in that case, I was thinking about the "UI" and "Has an effect in" sections of preference articles, specifically [[browser.cache.disk.capacity]] and [[browser.bookmarks.file]] in the context of article-writing guidelines, when the same preference applies to both products. I also mentioned in the separate "SeaMonkey" discussion above that I would probably stick with "Mozilla Suite" in new articles if the features applied to both and not mention SeaMonkey at all if it wasn't necessary. In other words, no one should be forced to refer to SeaMonkey at all. On the other hand, maybe no one should be forced to refer to Moziila Suite either... is that what you're saying? I would agree with you, if someone is writing a new article and his only experience is with SeaMonkey, he should not reference Mozilla Suite or Thunderbirs at all, and the article should have a disclaimer that it was written for SeaMonkey, etc (another reason for a SeaMonkey category). [[User:Alice Wyman|Alice Wyman]] 17:57, 18 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Knowledge_Base_changes&diff=22265Knowledge Base changes2006-01-27T19:40:25Z<p>Wintogreen: /* Question&mdash;how to use "SeaMonkey" in the kb from now? */</p>
<hr />
<div>{{org}}<br />
==Temporary introduction==<br />
This page has been created for several reasons.<br />
<br />
*It would be nice to have a place where new editors can introduce themselves and meet existing editors.<br />
*It would be good to allow new editors to safely propose content changes (minor or major) prior to implementing them.<br />
*It would be good to have a central location to discuss the style, content and organisation of this Knowledge Base. (Some of the ideas in [[Talk:Knowledge Base]] can be migrated here, leaving that page solely for discussion of the front page article itself.<br />
*This page is an attempt to address recent incidents that have occured on the KB where some groups of editors have been unaware of major changes being made by other groups of editors.<br />
<br />
We intend to place a link to this page in the "welcome to new editors" paragraphs found on the front page and from the other "entrance" pages such as [[Firefox]] and [[Thunderbird]] if it is deemed useful.<br />
<br />
We anticipate this page being the primary place to announce new suggestions. Please visit it regularly!<br />
<br />
==Welcome to new editors==<br />
Hello! Great to have you here. Please add a comment here :-)<br />
<br />
* Hello Knowledge Base! FJ reporting to duty! *bows at all* [[User:FatJohn|FatJohn]] 11:30, 3 January 2006 (UTC)<br />
<br />
==Hot topic&mdash;Making things less daunting for new editors==<br />
Several new editors (or potential editors) have felt a bit daunted by the [[rules]] for contributing. I think this is a shame; we want their contributions! (The rules are fairly comprehensive and are written formally; this is for the benefit of regular contributors. But it was never anyone's intention to discourage new editors.) I have added an introduction to the [[rules]] page, which states that they don't need to read everthing thoroughly. This could be controversial; please state your view here! Should we include that sentiment in other places too? And should we put a sticky in the forums which tries to bring new editors to the KB? --[[User:Mozcerize|Mozcerize]] 13:10, 8 January 2006 (UTC)<br />
:Looks good; you have a knack for writing these welcome intros. Where else would that sentiment be included? Instead of a forum sticky, I'd just use a regular thread in the General forums; the regulars will see it. A few suggestions: (1) The "Please don't be offended..." sentence can come out or be merged into the similar point in the "Editing courtesy" section. (2) The "Avoid superfluous information" section could go into In-house style. (3) The "Test editing pages" section could come to the very top, above "Editing courtesy", as a way to invite people to take the plunge into editing. (4) "Talking to authority" should come out; those links are all available in kb Organization category and aren't rules in the first place. (5) [[Rules/Templates]] should be renamed because those templates aren't rules; they're editing shortcuts and should be presented as such. --[[User:Wintogreen|wintogreen]] 14:36, 8 January 2006 (UTC)<br />
::I'll look into these suggestions soon! --[[User:Mozcerize|Mozcerize]] 17:50, 10 January 2006 (UTC)<br />
<br />
I suggest the rules be modified to state that you shouldn't post a notice on a page unless it adds value to the reader. For example, posting a notice stating that the name of the knowledge base page is in error (when its actually due to a limitation of the wiki software) just causes confusion and annoys the person who wrote the article. The reader doesn't care that we're using Wiki software. Note that I'm not arguing against a notice that an article needs rewriting. The reason I'm mentioning this in this section is because behavior that seems perfectly appropiate to somebody steeped in the wiki culture can be upsetting to a new editor who has never had to deal with collaborative writing with strangers.<br />
<br />
I'm not a wiki person. It was easy to pick up what I needed to know to edit knowledge base articles before we switched to categories. Its more difficult now. An example - I need to create a new category. I read Rules/Categories and it wasn't clear to me how to create a new category, though I understood how to make a category a subcategory because that didn't require any background knowledge. Please think about the barrier to entry you're accidentally creating by assuming a new editor has a wiki background. <br />
<br />
I don't think creating a thread will help attract new editors. I suggest you consider converting MozillaZine_Knowledge_Base:Formatting into a short primer on what you need to know to be an editor. The current article does a good job of covering what you need to know about formatting. But it <br />
doesn't cover other common tasks such as how you create a new article or how to categorize it. Yes, there are links to wiki documentation where you can find that but its rather overwhelming for somebody who may know a little HTML or bbcode and is not used to reading rules, in-house style guides, naming conventions etc. while learning yet another formatting syntax. Think of all that we're implying a person should read before doing something small such as update an existing article for a new version. Especially since they really don't need to deal with most of those topics until they create a new article, if they make an attempt to mimic what they see in the article they're editing. I think its telling that some of our most prolific forum posters such as Daifne, SKopischke, GordMcFee and Mr. Liu have never touched the knowledge base as far as I can tell. The current approach seems designed to tell you everything that you need to know to do it right in order to minimize cleanup by other editors. I think we should increase the risk that we'll have to cleanup after a new editor for a while if that makes it easier to lower the barrier to entry (whether its real or perceived).<br />
<br />
I'm suggesting that we make it easy for them to get started by letting them get started using just the primer, let them learn more of the conventions/customs (documented in the rules, guides etc.) later on as they tackle bigger tasks, and try to avoid giving them the impression they need to learn everything before they can do anything. Once thats in place its also easier for somebody to encourage somebody to contribute. <br />
<br />
It might also help if one or two names (perhaps Wintogreen?) were mentioned in the primer as volunteers that new editors are encouraged to contact via private messages for advice if they need it. --[[User:Tanstaafl | Tanstaafl]] 3:30 AM January 16, 2006 (PMT)<br />
<br />
<br />
I took the liberty of expanding the [[MozillaZine Knowledge Base:About|About]] page, in particular the "Contributing to the KB" section. If someone could please review it and revise where you think it can be improved, that'd be great. Note that I also added a "Need help with the wiki?" section at the end of the [[Help wanted]] page. That's my way of saying I don't want to be a designated go-to guy. ;-) --[[User:Wintogreen|wintogreen]] 19:14, 19 January 2006 (UTC)<br />
<br />
==Hot topic&mdash;replacing the FAQs and Issues pages with category navigation==<br />
Discussion of this proposal can be found on [[Talk:Rules/Categories]]). Some editors were not aware of this discussion (see [[Talk:Issues with Firefox]] and [[Talk:Rules/Categories#Flattening the Thunderbird categories]]). This was the main motivation for creating this page.<br />
<br />
To summarize the situation so far:<br />
<br />
Part of the motivation for implementing categories was to avoid the following situation which occurred with the original FAQs, Issues and Tips pages: article links had to be maintained manually; some articles appeared on more than one page; some articles didn't appear on any page. The result was that people had to look at all three pages to makes sure they didn't miss anything, and then perform a search as well. With categories, the danger that an article was never linked to from anywhere was removed, since category automatically list the articles. There was no opposition to removing the Tips pages.<br />
<br />
The suggestion to temove the FAQs and Issues pages was more controversial. Indeed, the problem with relying solely on category listings is that ''logical order'' is lost. The initial solution proposed was to use the editable part at the top of the category pages to recreate some logical order by factoring in parts of the FAQs and Issues pages.<br />
<br />
:My current opinion on this is that the FAQ and Issues pages should be kept, because they contain more info that could sensibly be placed in the category pages. However, I do think that they should both contain prominant links to the category pages, notifying the reader that there is more info on the KB than the selection of articles advertised on the FAQ and Issues pages. Indeed, I would suggest renaming "Issues " to "Common Issues with Firefox" to emphasise the fact that the Issues page is just a selection. --[[User:Mozcerize|Mozcerize]] 15:00, 2 January 2006 (UTC)<br />
<br />
:: First, thanks for the new discussion area and for the invitation to add comments. I've already added some comments to the [[Talk:Issues with Firefox]] page, back when it was first removed. I never did see the justification for removing either page, even if they are no longer linked from the front page. (I took it upon myself to restore them... I'm sorry it I stepped on anyone's toes but I was totally unaware of any discussion going on or a decision to remove the two pages. I strongly believe that both pages should be kept as they're a very handy way to organize and locate information, especially the FAQs page, which is unique in that the collection of links isn't duplicated anywhere else, alphabetically or not. Both pages are good places to include links to forum topics, release notes or other external links when there is no KB article covering the topic, plus the link descriptions give much more information than a simple title page link. I'm willing to help keep both pages organized and updated since I refer to them both so often. As far as the [[Issues with Firefox]] page, I've already pointed out in the intro that, "A link to an alphabetized list of current articles in the Category, Issues (Firefox) can be found at the end of this article." It might be a good idea to eliminate some of the less common issues on the page, such as the entire "Versions older than 1.0" section, and to emphasize that the page is a collection of "Common Firefox Issues" and is not exhaustive. I don't see the need for a new name but if someone else whats to rename the page "Common Firefox Issues" or similar, that's fine with me. [[User:Alice Wyman|Alice Wyman]] 20:47, 2 January 2006 (UTC)<br />
<br />
:::''"I'm sorry it I stepped on anyone's toes&hellip;."'' Not at all. Thanks for the points you've raised. The links to the forums and other offsite pages are indeed important. I was weighing up the idea of creating KB articles which act as wrappers for offsite links, that is, they have a useful title but their content is just a link. Ultimately, it would be good to have the info that they point to actually transferred to the article. (Anybody got a free week? ;-) I don't claim that this is an urgent task, but it would be good to have the offsite info represented somehow in the category listings. --[[User:Mozcerize|Mozcerize]] 11:25, 4 January 2006 (UTC)<br />
::::I made some changes to both the [[Firefox FAQs]] and [[Issues with Firefox]] pages today and made a note of this discussion on the Talk pages for each article. [[User:Alice Wyman|Alice Wyman]] 16:40, 7 January 2006 (UTC)<br />
:::::That's great; thanks! --[[User:Mozcerize|Mozcerize]] 12:15, 8 January 2006 (UTC)<br />
<br />
One of the current problems is that some of the categories mingle articles written for all of the products, even though you may have navigated there by selecting articles for one product. Somebody looking for information on Thunderbird privacy and security for example shouldn't see stuff such as Disabling autocomplete (Firefox), Mozilla Suite : FAQs : Mozilla Security or Parental controls. Ditto for navigating to Configuration::Preferences for Thunderbird and finding dozens of articles on preferences that Thunderbird doesn't support. I suggest we create a strategy for how to deal with this before creating a SeaMonkey category, which will just make it worse. My impression is that this is being dealt with piecemail by creating new versions of dozens of subcategories specific to an application. Is this what we want? --[[User:Tanstaafl|Tanstaafl]] 4:00AM, 16 January 2006 (PST)<br />
<br />
==Hot topic&mdash;the new front page==<br />
See [[Knowledge Base]] and [[Talk:Knowledge Base]].<br />
<br />
==New proposal&mdash;implementing "browse by UI feature" system for Firefox articles==<br />
See [[Firefox components]] and [[Talk:Firefox components]].<br />
<br />
==Question&mdash;how to use "SeaMonkey" in the kb from now?==<br />
With the SeaMonkey 1.0 release just around the corner, I've been wondering how we should adjust for the use of the "SeaMonkey" name in the kb. As it is now, the article-naming conventions and in-house style both specify that only "Mozilla Suite" is to be used. Since SeaMonkey has features not in the Suite, it seems like it would make sense to start referring to the proper product name when it's needed to differentiate it from the Suite; perhaps we could linkify "SeaMonkey" in such cases so that it leads back to the category page, where there could be a blurb about the two names being used in the kb. Thoughts? --[[User:Wintogreen|wintogreen]] 18:23, 4 January 2006 (UTC)<br />
:Maybe we could link to the [[Mozilla_Suite_:_FAQs_:_Status]] page if we needed to refer to SeaMonkey and mention somewhere that articles referring to "Mozilla Suite" may also apply to "SeaMonkey" and other unofficial Mozilla-based products. Correct me if I'm wrong but all "Mozilla Suite" articles should continue to apply only to the official Mozilla Suite 1.7.xx product. I figure a separate category should be set up for "SeaMonkey" just as there is a [[:Category:Nvu]]. [[User:Alice Wyman|Alice Wyman]] 16:35, 5 January 2006 (UTC)<br />
::In [[:Category:Preferences]] we're listing them both.--[[User:Np|Np]] 22:50, 5 January 2006 (UTC)<br />
:::I agree with Alice; it sounds like we should introduce a new category for Seamonkey. I would think that lots of the Mozilla Suite articles could also be placed in the new category for now (after putting a "this article was written for the Mozilla Suite but also applies to SeaMonkey" notice at the top of them). Sooner or later SeaMonkey will have progressed to the point that the Mozilla Suite articles will no longer apply. At this point, these articles should be taken out of the SeaMonkey category again, and new ones written purely for SeaMonkey. --[[User:Mozcerize|Mozcerize]] 11:31, 6 January 2006 (UTC)<br />
::::Well, hopefully it won't get too messy. I'm thinking I might make an article similar to [[Menu differences in Windows, Linux, and Mac]] for Thunderbird - Suite - SeaMonkey menu differences, so that instead of trying to stuff Suite/SeaMonkey menu sequences into TB articles I can just insert a link into the notice at the top that says "...written for TB but also applies to Suite/SeaMonkey (though some menu sequences may differ)". --[[User:Wintogreen|wintogreen]] 13:48, 8 January 2006 (UTC)<br />
:::::I agree with Wintogreen about the need for standard one-liner. I have no interest in spending time learning about Seamonkey or Mozilla Suite when writing a knowledge base article for Thunderbird, yet know I have to somehow mention them. --[[User:Tanstaafl|Tanstaafl]] 3:42AM, 16 January 2006 (PMT)<br />
<br />
::::::I've taken a stab at this with a new template -- [[Template:Tbsuite]], now in action [[Compacting folders|here]]. It lists both Mozilla Suite and SeaMonkey and links to the page Alice suggested. Some articles flagged like this will apply to both the Suite and SM, and some to SM only, but we can let the users of those respective apps worry about it from there.<br>As for creating SeaMonkey categories... what's to be gained by doing this instead of using the existing Mozilla Suite categories (or redirecting those to become SM categories, as I think can be done)? If SM features or menu sequences need to be differentiated from those for the Suite, that can be done easily enough within the article (like has been done for different TB versions in [[Multiple SMTP servers (Thunderbird)|this article]]). Considering that the Suite categories are a mess as is, with no one taking care of them, why double the mess by creating a parallel set of SM categories? --[[User:Wintogreen|wintogreen]] 17:00, 16 January 2006 (UTC)<br />
<br />
::::::: I see your linked text in the [[Template:Tbsuite]] is ''Mozilla Suite / SeaMonkey'' which might make someone think of them as the same product, renamed. The [[Mozilla_Suite_:_FAQs_:_Status | linked page]] says that "the Suite is no longer an official product" which is ambiguous. I was considering them as separate products when I suggested a separate category for SeaMonkey, with Mozilla Suite being the official product, especially since both products are available and Mozilla Suite is continuing to be updated, if only for security bug fixes. I noticed on the [[Category_talk:Preferences]] page containing guidelines for preference articles, the [[Category_talk:Preferences#Formatting | Formating section]] also referenced ''Mozilla Suite/SeaMonkey'' as a single product, while in preference artilces supposedly based on those guidelines, they are listed as separate products. See my comments under [[Knowledge_Base_changes#Article-writing_guidelines | Article-writing guidelines]] below. [[User:Alice Wyman|Alice Wyman]] 14:16, 17 January 2006 (UTC)<br />
<br />
:::::::: Hi Alice. What I've been thinking, since I made the trial template, is that the [[Mozilla_Suite_:_FAQs_:_Status | linked page]] should be like the [[Firefox]] and [[Thunderbird]] pages PLUS serve as a kind of disambiguation page&mdash;i.e., by summarizing the Suite/SeaMonkey connection and noting that a handful of articles claiming to apply to the Suite/SeaMonkey may really only apply to one of them, due to changes since the Suite development stopped. That page would have to be modified, or a different page used instead. Yes, they are separate products (or, one's a "product" and one's a "project"), and referring to them in a template as "Mozillla Suite/SeaMonkey" is not ideal. But as tanstaafl pointed out, we do need a practical, simple way of referring to "the Mozilla Suite and/or SeaMonkey" in TB articles. I'm open to other ideas. How about "SuiteMonkey"? --[[User:Wintogreen|wintogreen]] 16:53, 17 January 2006 (UTC)<br />
<br />
::::::::: Hi, wintogreen. I agree the [[Mozilla_Suite_:_FAQs_:_Status | linked page]] for the template should be modified, or better yet, create a new page explaining the Mozilla Suite and SeaMonkey commonalities and differences. In most cases, just a template will do, whatever you want to use as the linked text (I would go with "Mozilla Suite and SeaMonkey") . In new articles that apply to both products, I would probably stay with "Mozilla Suite" with a link to a "Mozilla Suite and SeaMonkey" template, and not refer "SeaMonkey" at all in the article unless I was referring to certain features that are only present in SeaMonkey 1.0 or later. The problem I see is inconsistency. Look at [[browser.bookmarks.file]] and [[browser.cache.disk.capacity]] under "UI". The first has "Mozilla Suite" and the second has "Mozilla Suite and SeaMonkey". By the way, I was editing below under [[Knowledge_Base_changes#Article-writing_guidelines | Article-writing guidelines]] before I saw your reply here. [[User:Alice Wyman|Alice Wyman]] 18:03, 17 January 2006 (UTC)<br />
<br />
:::::::::: I'd be more inclined to use "SeaMonkey" in an article if I know for sure that it applies to SeaMonkey and especially if I don't know if it also applies to Mozilla Suite (which will more and more be the case as time passes). --[[User:Wintogreen|wintogreen]] 19:55, 17 January 2006 (UTC)<br />
<br />
::::::::::: ''...if I don't know if it also applies to Mozilla Suite.....'' What, you don't plan on keeping both versions, for testing and such? ;-) In that case, if you didn't know for sure that a new article applied to both products, create the category "SeaMonkey" and place the new article there, with a reference that the article was written for SeaMonkey but may also apply to Mozilla Suite? [[User:Alice Wyman|Alice Wyman]] 21:27, 17 January 2006 (UTC)<br />
::::::::::::You wouldn't believe the number of new Thunderbird users who can't even get it straight whether the dedicated email client they're using is called Thunderbird, Firefox, Firebird or Mozilla. Wintogreens one-liner about Mozilla Suite / Seamonkey alerts somebody that its likely (but not 100% sure) the article also applies to those products and minimizes the amount of work the author does. If somebody ever confirms it applies then they have the option of adding the article to the Mozilla Suite and/or SeaMonkey category and/or stating something specific about the differences in support. I guess I'm arguing that the expense of avoiding inconsistency isn't worth it given all of the bigger fish to fry. --[[User:Tanstaafl|Tanstaafl]] 2:40AM, 18 January 2006 (PMT)<br />
<br />
::::::::::::: Update: since the above-mentioned <nowiki>{{Tbsuite}}</nowiki> template is now in use and linking to [[Mozilla Suite : FAQs : Status]], I tried to fill out that page to make it a bit more useful. That page doesn't have to be the permanent target for the template, of course; if someone wants to move the relevant content elsewhere and update the template link accordingly, feel free. --[[User:Wintogreen|wintogreen]] 19:40, 27 January 2006 (UTC)<br />
<br />
=== Specific questions re: "SeaMonkey" ===<br />
Now that the discussion has been raging for a while, I've decided to list up what seem to be some of the key issues regarding the use of "SeaMonkey" in the kb. With numbers, for your commenting convenience. --[[User:Wintogreen|wintogreen]] 20:22, 18 January 2006 (UTC)<br />
<br />
# In kb articles in general, should Mozilla Suite and SeaMonkey be ''treated'' as two distinct products or as one product (i.e., akin to earlier and later versions of the same product)?<br />
# If they are to be treated as two distinct products, should we normally refer to them using both product names ("Mozilla Suite and SeaMonkey")?<br />
# If we decide to normally use just one product name (either "Mozilla Suite" or "SeaMonkey") to refer to both, which name should we use?<br />
# Should any special guidelines apply to the [[:Category:Preferences|Preferences]] articles (different from those for the regular user-support articles)?<br />
# Should there be separate sets of categories for Mozilla Suite and SeaMonkey?<br />
<br />
<br />
Very brieflly, here are my own thoughts on the above. --[[User:Wintogreen|wintogreen]] 20:24, 18 January 2006 (UTC)<br />
# In general, as one product. I don't think kb users will be confused by this, and it will be easier for us editors as well.<br />
# No. Using both names all the time would be awkward (except perhaps in a simple template like [[Template:Tbsuite|this]]).<br />
# SeaMonkey. That will seem the obvious choice two years from now.<br />
# Not sure.<br />
# No. I can't see any benefit in doing this. <br />
------------------------------------------------<br />
I've added my thoughts below: [[User:Alice Wyman|Alice Wyman]] 21:16, 18 January 2006 (UTC)<br />
# In general, as two products, similar to the way Netscape 7.xx and Mozilla Suite are treated.<br />
# Either product name can be used with a note that it was written for one but may also apply to the other, or that it applies to both. If writing new articles for both, use both names only if necessary to differentiate and note any differences within the article as is done now for "Firefox 1.0.7" and "Firefox 1.5" differences. <br />
# ---<br />
# I see the question as whether the "de facto" preference article guidelines [[:Category_talk:Preferences | here]] should be formalized and made easier to find by new editors Check any of the [[:Category:Preferences]] articles that have been written already and you will see that they all follow the same format. When I wrote a new preference article it was immediately edited to add the "Has an effect in" section I omitted.<br />
# Yes. This is needed for new articles written for SeaMonkey 1.0 where the writer does not know if the content also applies to Mozilla Suite, or knows for sure that it doesn't.<br />
------------------------------------------------<br />
<br />
==New proposal&mdash;"Startup and performance" category==<br />
I'd appreciate some input on the title for this category, esp. as it would be best to choose a category name that works for all apps. Please add your comments at [[Talk:Rules/Categories#Some_new_categories]]. --[[User:Wintogreen|wintogreen]] 11:15, 5 January 2006 (UTC)<br />
:This proposal is dead as far as I'm concerned. The only question is whether "Startup and performance" would make a viable category name for any application. If not, then it'd be best to remove the links from the category tree at [[Talk:Rules/Categories]]. --[[User:Wintogreen|wintogreen]] 08:07, 17 January 2006 (UTC)<br />
<br />
<br />
==Article-writing guidelines==<br />
===(Also related to SeaMonkey references in the kb and making things less daunting to new editors)===<br />
The [[Category talk:Preferences]] page includes guidelines for writing preference articles. Should these guidelines (and possibly guidelines for other article categories) be formalized? Where would you want to place the guides in the kb so that people can find them? Here is part of what I wrote to [[User Talk:Unarmed | Unarmed on his Talk page]] ''It never occurred to me to look on a Talk page for article-writing guidelines (I would think that anything on a "Talk" page is "informal"). I'd suggest formalizing those "guidelines" for anyone wanting to write a new preferences page.'' <snip> ''I'm assuming you want people to follow a certain format in a category like Preferences since that's the impression I got from Np. If that's the case, you should link to an article explaining what you want followed in [[Rules]] or [[In-house style]]. I'm not sure where you would place an article like that but I would guess somewhere in [[:Category:MozillaZine_Knowledge_Base_organization]].'' [[Category_talk:Preferences#Moving_some_of_this_to_a_separate_page | I've also suggested]] that the discussion about formalizing those guidelines be moved here. <br />
Since the question about SeaMonkey references in the kb has also come up, the [[In-house style]] page should be amended to make clear whether Mozilla Suite and SeaMonkey should be referenced as the same product (e.g. "Mozilla Suite/SeaMonkey") or separate products ("Mozilla Suite and SeaMonkey") and under what circumstances. For example, [[Category_talk:Preferences#Formatting]] is using ''Mozilla Suite/SeaMonkey'' to refer to a single product, while in preference articles supposedly based on those guidelines, both are listed as separate products, as in the "UI" and "Has an effect in" sections of [[browser.bookmarks.file]] and [[browser.cache.disk.capacity]]. I would suggest only using "SeaMonkey" as a separate product name when referring to features not found in Mozilla Suite. (Is the "Has an effect in" subheading listing Netscape SeaMonkey Firebird and Phoenix even needed?) [[User:Alice Wyman|Alice Wyman]] 11:51, 17 January 2006 (UTC)<br />
:Um... you're assuming somebody knows whether it applies to either of those two applications when writing an article for another application. Thats not realistic, and just makes it more daunting to new editors. I know my first reaction to the change you propose would be I'd like to help out users of other applications but I don't need this grief, and only mention Thunderbird the next time I write a email article. Being slightly inaccurate is healthy in some circumstances. Especially when you consider the slow pace of updating existing articles. [[User:Tanstaafl|Tanstaafl]] 2:45AM, 18 January 2006 (PMT) <br />
:: What proposal? I did propose that the [[In-house style]] page should be amended to make clear whether Mozilla Suite and SeaMonkey should be referenced as the same product (e.g. "Mozilla Suite/SeaMonkey") or separate products ("Mozilla Suite and SeaMonkey") and under what circumstances. If you are responding to what I said immediately above, "I would suggest only using "SeaMonkey" as a separate product name when referring to features not found in Mozilla Suite."..... then, in that case, I was thinking about the "UI" and "Has an effect in" sections of preference articles, specifically [[browser.cache.disk.capacity]] and [[browser.bookmarks.file]] in the context of article-writing guidelines, when the same preference applies to both products. I also mentioned in the separate "SeaMonkey" discussion above that I would probably stick with "Mozilla Suite" in new articles if the features applied to both and not mention SeaMonkey at all if it wasn't necessary. In other words, no one should be forced to refer to SeaMonkey at all. On the other hand, maybe no one should be forced to refer to Moziila Suite either... is that what you're saying? I would agree with you, if someone is writing a new article and his only experience is with SeaMonkey, he should not reference Mozilla Suite or Thunderbirs at all, and the article should have a disclaimer that it was written for SeaMonkey, etc (another reason for a SeaMonkey category). [[User:Alice Wyman|Alice Wyman]] 17:57, 18 January 2006 (UTC)</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Mozilla_Suite_:_FAQs_:_Status&diff=22264Mozilla Suite : FAQs : Status2006-01-27T19:21:40Z<p>Wintogreen: trying to make this more useful, as it's now the target for the {{Tbsuite}} template</p>
<hr />
<div>== Development status of the Mozilla Suite ==<br />
<br />
The 1.7 release of the Mozilla Suite is the last major release to be an official mozilla.org product. This release will be maintained with 1.7.x releases to fix known security problems or other critical issues but there will be no official Mozilla Suite 1.8 release. This will enable the foundation to devote its resources to the standalone applications Firefox and Thunderbird.<br />
<br />
Although the Suite is no being developed by Mozilla as an official product, it will continue to evolve as a community-led ''project'' and will recieve substantial support from the foundation. In particular, the development community will still use mozilla.org's webtools such as CVS, LXR and [[Bugzilla]], and foundation members have provided significant advice to the community on how to organise successful future releases of a Gecko-based application suite. The project will be "driven" by members of the community who will be responsible for maintaining code, dictating the release schedule and performing QA on the final releases. More information on the organisational structure that has developed to maintain the suite and manage future releases is on the [http://wiki.mozilla.org/SeaMonkey:Home_Page SeaMonkey homepage] of the [http://wiki.mozilla.org/ mozilla.org wiki]. <br />
<br />
Since this community-led project will not result in an official Mozilla Foundation product, it has been agreed that the name and version number of the next release must change. In particular it is not possible to use the "Mozilla" trademark on an unofficial product. The name of the next release will be "SeaMonkey 1.0" (Seamonkey is the longtime codename of the Mozilla Suite).<br />
<br />
== Differences between the Mozilla Suite and SeaMonkey ==<br />
<br />
Despite the name change, SeaMonkey 1.0 will feel very familiar to Mozilla Suite users, but it will incorporate numerous new features, UI improvements, and bugfixes. Some of these will be listed in the release notes, available through the [http://www.mozilla.org/projects/seamonkey/ SeaMonkey project page].<br />
<br />
<br />
''This section is a [[stub articles|stub]]. You can help MozillaZine Knowledge Base by expanding it.''<br />
<br />
=="Mozilla Suite" vs. "SeaMonkey" in Knowledge Base articles==<br />
<br />
Contributors to this Knowledge Base are in the process of [[Knowledge Base changes|trying to formulate a scheme]] for how best to refer to the Mozilla Suite and SeaMonkey in Knowledge Base articles and categorize the articles related to each. Until that scheme is worked out and eventually implemented, you may find one or both names used in different articles. For the time being, it is generally safe to assume that all references to "Mozilla Suite" also apply to "SeaMonkey".<br />
<br />
In some articles, especially those written for Thunderbird, there may be a note stating that the article "also applies to Mozilla Suite / SeaMonkey". This could mean that the article applies to both products (most likely) or perhaps only to SeaMonkey (e.g., due to new features in SeaMonkey that are lacking in the Mozilla Suite). Article writers often don't know the specific differences between Mozilla Suite and SeaMonkey and thus use the shorthand "Mozilla Suite / SeaMonkey" note to flag articles that might be of interest to Mozilla Suite and/or SeaMonkey users.<br />
<br />
==See also==<br />
* [[Summary of Mozilla products]]<br />
* [[Mozilla Suite]] articles in this Knowledge Base.<br />
<br />
==External links==<br />
* [http://www.mozilla.org/seamonkey-transition.html Transition plan] on the decision to not release a version 1.8 of the Mozilla Suite<br />
* [http://wiki.mozilla.org/SeaMonkey:Home_Page SeaMonkey homepage] in the mozilla.org wiki<br />
* [http://weblogs.mozillazine.org/seamonkey/ SeaMonkey weblog] with updates on development progress<br />
* [http://www.mozilla.org/projects/seamonkey/ SeaMonkey product page] where you can download SeaMonkey and access the release notes<br />
* [http://www.mozilla.org/products/mozilla1.x/ Mozilla Suite product page] where you can download the latest 1.7.x version of Mozilla Suite<br />
<br />
[[Category:Mozilla Suite]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Signatures_-_Thunderbird&diff=22263Signatures - Thunderbird2006-01-27T17:07:34Z<p>Wintogreen: /* Single signature per account */ link update</p>
<hr />
<div>==Single signature per account==<br />
Thunderbird allows you to have a different signature for each of your email accounts. Instructions on how to create a signature file and use it in Thunderbird are available [http://opensourcearticles.com/thunderbird_15/english/part_03 here]. If you want your signature to include graphics or html-formatted text such as colors or boldfacing, then create your signature file as an html document and save it with the ".html" file extension. For more information on signature blocks, including the signature separator ("-- ") that Thunderbird inserts before your signature text, see [http://mailformat.dan.info/trailers/sigblocks.html Dan's Mail Format Site].<br />
<br />
===Tip for making an html-formatted signature===<br />
If you don't know how to make an html file to use for a signature, you can try the procedure described below.<br />
# In Thunderbird, click on the "Write" button to compose a new message.<br />
# Type in the text you want to use for your signature and add whatever formatting you want (font style, color, boldfacing, etc.).<br />
# Select the text you want in your signature (or go to "Edit -> Select All" if you want the whole message as your signature).<br />
# From the "Insert" menu, choose "HTML...".<br />
# Select the text in the window that pops up and copy the selected text ("Ctrl+C", or right mouse click and select "Copy").<br />
# Open your favorite text editor (such as Notepad) and paste in the text you just copied.<br />
# Save the file to your computer, giving it a name with the ".html" extension (such as "signature1.html").<br />
# In Thunderbird again, go to "[[Menu differences in Windows, Linux, and Mac|Tools -> Account Settings]] -> <Account Name>".<br />
# Check the "Attach this signature" option.<br />
# Click the "Choose..." button and attach the signature file that you just created and saved on your computer.<br />
<br />
===To insert a promotional button in your signature===<br />
If you want to include a promotional button for Thunderbird or Firefox in your signature, get the raw html code for the button from [http://www.mozilla.org/products/thunderbird/buttons.html here] (Thunderbird) or [http://www.spreadfirefox.com/?q=affiliates/homepage here] (Firefox). Do as described above for making an html-formatted signature, but at step #2, put the cursor in the message body where you want the button to appear and then go to "Insert -> HTML". In the dialog box that pops up, paste in the raw html code for the button and click "Insert" to close the dialog. See this [http://forums.mozillazine.org/viewtopic.php?t=137619 forum thread] for further tips.<br />
<br />
==Multiple signatures per account==<br />
===Via an extension===<br />
If you want to have more than one signature per e-mail account or choose from a variety of signatures when composing mail, your best option is to use the [https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&id=611 Signature Switch] extension. It will allow you to easily select from multiple signatures in the Compose window by using a [[Toolbar customizing (Thunderbird) | toolbar button]] or via the context menu (right-click).<br />
Other options:<br />
* The [https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&id=640 Quicktext extension]: adds a menu in the Compose window from which you can select your own pre-defined text to insert at the current cursor location. Morever, the extension allows you include variables such as sender's/recipient's e-mail address, message subject, and date. See the [http://www.hesslow.se/quicktext/ Quicktext extension homepage] for further information.<br />
* The [http://www.extensionsmirror.nl/index.php?showtopic=2177 Signature extension]: similar to but simpler than the Quicktext extension, the Signature extension lets you insert pre-defined text wherever the cursor is located in the message body. Inserts plain-text only and does not allow variables to be used.<br />
* The [http://tagzilla.mozdev.org/ Tagzilla extension]: can be used to insert "taglines" or signatures in e-mail messages. Note that you must also install the [http://extensionroom.mozdev.org/more-info/jslib JSLib] extension before installing Tagzilla. See [http://forums.mozillazine.org/viewtopic.php?p=535118#535118 this thread] for a few comments on Tagzilla limitations with regard to e-mail signatures.<br />
[[Extensions (Thunderbird) | Read this]] if you do not know how to install a Thunderbird extension.<br />
<br />
===Via multiple identities===<br />
Another way to create multiple signatures for a single account is to create [[Thunderbird : FAQs : Multiple Identities|multiple identities]] and to create a separate signature for each identity. Once you have created your identities, make a separate signature file for each as described above. To assign one signature file to one identity:<br />
# Go to "[[Menu differences in Windows, Linux, and Mac|Tools -> Account Settings]]", click on the account name (in the left-hand pane), and then click on the "Manage Identities..." button.<br />
# Select an identity from the list and click the "Edit..." button.<br />
# Click the "Settings" tab, check the "Attach this signature" option, the click the "Choose..." button to attach a signature file.<br />
# Finally, click the "OK" button and repeat the above steps for your other identities.<br />
<br />
[[Category:Composing messages (Thunderbird)]]<br />
[[Category:E-mail account setup (Thunderbird)]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Archiving_your_e-mail&diff=22251Archiving your e-mail2006-01-27T10:52:28Z<p>Wintogreen: fixing menu sequences, etc.</p>
<hr />
<div>:''This article was written for Thunderbird but also applies to Mozilla Suite, except where noted.''<br />
<br />
Thunderbird does not have a built-in feature for archiving e-mail. Below are listed some alternatives to or workarounds for archiving.<br />
<br />
==Using the Buttons! extension==<br />
The Buttons! extension (for Thunderbird only) provides numerous buttons that you can add to your Thunderbird toolbar, including an "Archive!" button. Once you've configured the extension, just select one or more messages in the message-list pane and then click the Archive! button. Those messages will be filed in the archive folder that you've specified. Users of Gmail will find this very similar to the way Gmail's archiving feature works. However, archiving with the Buttons! extension is more flexible because you can set up the extension to use any archive folder of your choice, and you can also specify more than archive folder (with one set as default).<br />
<br />
For further information, see the [http://www.chuonthis.com/extensions/buttons.php Buttons! extension homepage]. The latest version of the extension can be downloaded there or at the [http://www.extensionsmirror.nl/index.php?showtopic=164 Extensions Mirror].<br />
<br />
==Using searches==<br />
Instead of individually selecting messages to be archived, you can instead use an [[Searching messages | advanced search]] to quickly find all messages in various folders and subfolders that meet your search criteria (e.g., older than 90 days), and then move those messages all at once to an archive folder of your choice. Here's one possible way to do this:<br />
# Create a new folder in [[Local Folders]] and call it "Archive".<br />
# Go to the "Edit" menu and choose "Find -> Search Messages...".<br />
# Where it says "Search for messages in", select "choose this folder" for the account whose messages you want to archive. If you are using Thunderbird's [[Global Inbox]] with multiple POP accounts, you can select Local Folders as the account.<br />
# Make sure that the checkbox for "Search subfolders" is checked.<br />
# Define the search criteria as "Age in Days is greater than 90" (or however many days you want).<br />
# Click the "Search" button. The list of "old" messages will appear in the lower pane.<br />
# Select all messages listed in the search results, and use the "File" button to move them all to the "Archive" folder you created in step 1.<br />
# If you have more than one mail account that you want to archive, repeat the above steps for each additional account. (If all your accounts are using the Global Inbox, you will not need to repeat the above steps.)<br />
Note:<br />
* After step 6 above, Thunderbird users can also make a [[Saved Search]] folder so that in the future this same search (steps 2-6) can be performed with a single click. If you want to exclude certain folders from being searched, just right-click on the Saved Search folder, choose "Properties...", click the "Choose" button, and (de)select folders as desired.<br />
<br />
* The above procedure will put all of your archived mail into a single folder, and it thus will not preserve your folder structure.<br />
<br />
==Using the MboxImport extension==<br />
The MboxImport extension (for Thunderbird only, and currently not for Mac OS X) allows you to easily import mailbox files into Thunderbird. Because it also allows you to export mail folders from Thunderbird&mdash;you can export a single folder such as the Inbox or even all folders and subfolders for an entire account&mdash;it can be a useful tool for archiving. This is especially so if you want to periodically remove archived messages from your active [[profile folder | profile]] and store them in an external location, and only import them back into Thunderbird if needed. For this purpose, the MboxImport extension would work well in conjunction with the Buttons! extension or searches, as described above.<br />
<br />
For further information, see the [http://nic-nac-project.de/~kaosmos/mboximport-en.html MboxImport extension homepage]. The latest version of the extension can be downloaded there or at the [http://www.extensionsmirror.nl/index.php?showtopic=2074 Extensions Mirror].<br />
<br />
==Using MozBackup (Windows only)==<br />
The [[MozBackup]] utility can be used to back up your entire Thunderbird [[profile folder | profile]], including all downloaded mail, and it will preserve the folder structure of your mail when restored. Here's one way you could use MozBackup for archiving:<br />
# [[compacting folders | Compact folders]] and then exit Thunderbird.<br />
# Launch MozBackup and use it to make a backup of your Thunderbird profile. (Detailed instructions are [[MozBackup | here]].)<br />
# Restart Thunderbird.<br />
# As described in the "Using searches" section above, do an [[searching messages | advanced search]] of your mail, but instead of creating an "Archive" folder (step 1) and filing all the old messages into it (step 7), simply delete all the old messages. These messages will all have been saved in in the backup you made with MozBackup, so it shouldn't cause any harm to delete them from your active Thunderbird profile.<br />
Note:<br />
* If "archiving" your mail in this way, there will be some overlap between the mail in the MozBackup backup and the mail in your active Thunderbird profile, since MozBackup will back up all downloaded mail in the profile regardless of age.<br />
* [[IMAP]] users: If you store your messages in remote folders then MozBackup will only back up the headers unless you download a copy of the messages first. One way to do that is to right-click on the remote folder, select "Properties -> Offline" and then press the "Download Now" button. If you used "Tools -> Account Settings -> Offline & Disk Space" instead that doesn't just download a snapshot of the remote folder, it keeps a local copy synchronized with the remote copy. In both cases you need to use "File -> Offline -> Work Offline" to access those folders within Thunderbird. <br />
<br />
==Using IMAPSize (IMAP accounts, Windows only)==<br />
<br />
If you store your messages in remote folders you could use [http://www.broobles.com/imapsize/ IMAPSize] to incrementally back up messages from one or more folders or accounts as .EML files in a directory on your hard disk and then back up those files normally. An incremental backup means that the messages that have already been backed up will not be backed up (downloaded) again. You can back up using either a batch file or the GUI. The Account/RestoreBackup menu is used to restore backups. <br />
<br />
==Other information==<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=93094 Bug 93094]: please use only to view the status of the enhancement request or to vote for it (do not add "me too" comments).<br />
* [[Mail_Utilities | Mail utilities]]<br />
<br />
[[Category:Organizing and finding messages (Thunderbird)]] [[Category:Mozilla Suite]]</div>Wintogreenhttp://kb.mozillazine.org/index.php?title=Import_calendars_and_contacts_into_iPod&diff=22250Import calendars and contacts into iPod2006-01-27T10:42:28Z<p>Wintogreen: {{cleanup}}</p>
<hr />
<div>{{cleanup}}<br />
{{Tbsuite}}<br />
= How-to guide for importing calendar events & contacts into iPods =<br />
Below is outlined separately the steps taken to import ''calander events'' and ''address book contact'' entries into your iPod. Please note that the steps are for Windows-PC systems only. <br />
== Importing '''calendar''' data into an iPod ==<br />
<br />
:1. Bring up the calendar inside Thunderbird (probably also ok with Sunbird, did not try though)<br />
<br />
:2. Select ALL events in the filter window and highlight all events:<br />
<br />
::http://img30.imageshack.us/img30/3669/allevents3lt.jpg<br />
<br />
:3. Use '''File->Export Selected Events''' command to save a file with the specific filename of '''iSync-Calendar.ics''' onto your computer <br />
<br />
::http://img30.imageshack.us/img30/3882/exportimage7wf.jpg<br />
<br />
::http://img30.imageshack.us/img30/8922/exportsave0fy.jpg<br />
<br />
:4. Connect your iPod as you normally would<br />
:5. Open up your file browser and copy your saved '''iSync-Calendar.ics''' file into the iPod's ''Calendars'' folder<br />
<br />
::http://img39.imageshack.us/img39/8854/copycal2ipod3pa.jpg<br />
<br />
:6. '''''View your results in your iPod'''''<br />
<br />
== Importing '''contacts''' data into an iPod ==<br />
<br />
:1. Get the freeware application called '''Dawn''' from [http://www.joshie.com/projects/dawn/ Dawn's home page]<br />
<br />
:''(Latest version 5.3 supports exporting Thunderbird contacts)''<br />
<br />
:2. Run '''Dawn''', and use '''File->Open->Open Address Book''' command. This will bring up '''Dawn's''' dialog box of supported import databases, choose ''Thunderbird'' and your ''address book'' <br />
<br />
::http://img39.imageshack.us/img39/7678/dawntbimport7dv.jpg<br />
<br />
:3. '''Dawn''' will display all your contacts at this point, so use the '''File->Save->Save As File''' command to save file with the specific filename of '''iSync.vcf''' to your computer, using the ''Save-As type'' '''Becky! Address book'''. <br />
:''I know this is strange, but the resultant file is good for iPod - I've contacted the author about supporting iPod here as well'' <br />
<br />
::http://img39.imageshack.us/img39/2039/dawnsaveasfile4en.jpg<br />
<br />
::http://img39.imageshack.us/img39/1183/dawnsavedialog0cm.jpg<br />
<br />
:4. Connect your iPod as you normally would<br />
<br />
:5. Open up your file browser and copy your saved '''iSync.vcf''' file into the iPod's "Contacts" folder<br />
<br />
::http://img39.imageshack.us/img39/6221/copycontacts2ipod9rz.jpg<br />
<br />
:6. '''''View your results in your iPod'''''<br />
<br />
[[Category:Thunderbird]] <br />
[[Category:Address Book (Thunderbird)]]</div>Wintogreen