Cannot file a bug on the trac + The bug
I logged in and registered to http://trac.pcbsd.org/ as "shlomif", but I cannot start a new bug. It says:
Context Navigation Warning: <acct_mgr.web_ui.MessageWrapper object at 0x87e2de90> Error: Forbidden TICKET_CREATE privileges are required to perform this operation TracGuide — The Trac User and Administration Guide
Please fix it so that non-privileged users will be able to report bugs.
And here's the bug I wanted to report: I have been unable to install PC-BSD 7.1.1 on a Virtual Box VM (running on top of a Pentium 4 2.4GHz with 2.5GB of RAM running Mandriva Linux Cooker ) either from the first CD or both the first and second CD. It keeps asking me for the next CD with only an "OK" button and if I don't give it this CD, then the installation needs to be aborted, and the installed partition is left at an unusable state. As far as I recall, no installation of any Linux distribution I tried ever required more than one essential CD, and could always finish with just one CD, including today, so I think PC-BSD should follow suit, and not require more than one CD for installation.
I realise that if you make your software more idiot-proof, then nature will come up with better idiots, but eventually you can deal with a large number of complaints by eliminating many common stumbling blocks.
Please contact me at my contact page., though I'll try to monitor this wiki on my RSS reader.
Shlomif 11:30, 28 November 2009 (UTC)
Accessibility of handbook & possible confusion
Houston we have a problem. There are a few things we may not have considered that may cause trouble for users seeking help, especially those who either prefer to use google or online help, and/or those who have not yet installed it and therefore do not have the pdf or link on their desktop. There are further problems in the situation where a firewall is involved, since the most accurate version of the handbook (8.2) for anyone not working with/on the eventual upcoming release (v9.0) may be denied them due to its location on ftp.
I have tried to improve clarity on the pcbsd users handbook page but that only helps when reaching that page from other wiki links or the main wiki url. When google is used to locate help for example: 'google pcbsd multimedia' then your first result is a link within the new v9.0 handbook. This may be for two reasons, the v9.0 is using the same former locations (urls) of the 8.2 handbook, and secondly, Google may not (or does not) reference/"crawl" ftp sites.
It seems something should be changed, but I am not certain what/how, some ideas:
- An indication in the sidebar for versions of the handbook.
- A background image for the v9.0 handbook to indicate 'not for prime-time' but this would need to be a global background only affecting the unfinished/unpublished v9.0 handbook and/or other non-finalized things.
- Similar to and possibly in addition to above. A global footer (possibly a floating footer which stays on the bottom of the viewing window) that provides a notice and link to the current 8.2 handbook.
- Give the 8.2 version a static location. This may not be necessary to prevent confusion, but there may need to be a workaround for those locked out of the ftp site by firewalls.
--Tigersharke 15:29, 10 April 2011 (PDT)
Also I do not know if this is necessary to include somewhere in here about people new to unix, freebsd, and of course pcbsd. here is freebsd article about just that. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/new-users/index.html There's more UNIX manuals and sites that freebsd references for users as well. I do not know if we should only reference them, incorporated into the text, or both. Personally downloaded all of them to review and summarize them. Inputs are welcomed. --"What may be obvious to you, may not be obvious to others. That's why we have to write about them." 23:23, 17 July 2011 (PDT)
UPDATE: I need an answer before 11/1/11 to make my decision.
Removal of Old Posts Vote
I ask permission for deletion of the following posts grouped in comment tags < ! - - MfD Start - - > < ! - - MfD End - - > . I only need one member to agree of the changes. Me or the next member may make the edit. (MfD = marked for deletion). "What may be obvious to you, may not be obvious to others. That's why we have to write about them." 15:40, 19 October 2011 (PDT)
I have made some adjustments to the NavHeader which should remove the need for the localized version. Please take a look at how the newer NavHeader template reacts when traversing within the localized segment, such as /de. I switched Ziele und Funktionen to use the standard NavHeader. As you may notice, the new templates 'Next' and 'Previous' and 'returnTOC' and 'TOC' will contain a list of the appropriate translated words for each language id.
I plan to add further refinements for the rest of the wiki as needed. I had been attempting to solve the challenges of localizing the wiki when a site malfunction seemed to have taken away all my efforts, but I happen to have run across some breadcrumbs that survived. I have also been away from doing much editing or template work on the wiki for quite some time- at least in part due to sorrow over the loss of hard gained success (with a template relating to localized links).
I noticed how you have managed to translate many different things by using "custompagename" and other similar variables that exist in a number of templates. I hope to make further improvements on the wiki so that those changes might not be needed. I have to think a bit more on some wrinkles as they appear.
An additional new template 'References' is now available to localize the word "References" and is used (transcluded) by the Refheading template. As with the other templates which exist to localize specific words, it will give a message directed toward translators instructing them where and what to localize.
Some odd template issues
We may have to fly with what we have for the moment. As near as I can tell, the /en pages have some small template-induced errors with the hover link text on the NavHeader but this is due to the translation system's lag time which acts like a cache. Once the system catches up, I will look at it again to verify whether it is still an issue. I hope that everything continues to work properly in Ziele und Funktionen.
I am currently baffled and must be getting hindered by cache somewhere. The one /de page that I switched back to the standard NavHeader continues to work regardless of the modifications I make, while the 'base' page and /en page continue to have the weird bug. The main good news is that it is not a functional problem, only an aesthetic one.
Ok. I solved the challenge for the hover text (for the left) but I've discovered another bit of oddness. The wiki allows the pagename to be localized, BUT, the magicword I am using in the NavHeader template to shift the title below the icons does not work, it does not get localized (seems to take it from the URL). This is undoubtedly the reason for using the custompagename. I want to solve this issue as well, and see if the same translated data could be used for other templates. Currently using the standard NavHeader template without 'custompagename' causes a duplication of the pagename though non-localized. The real solution may be an adjustment to site CSS somehow. It will take a bit of exploration and effort.. so until then I will adjust the 'right' side of the NavHeader template effect to match the left.
Just when i think everything is solved, the cache effect seems to bite me. I will have to look at the "solved" problems again and see whats going on.
I have done some exploration and experimentation with the wiki CSS, but I still have not figured out how to get things working as I desire. The NavHeader has been adjusted to be one large table instead of two, and some other tweaks.
There must be an easier way. I discovered another way (via CSS) to hide the page title but this affects the entire site entirely, so I will have to find another way or some method of limiting it to the handbook pages portion of the wiki. Trial and error lead me to ways of limiting the effect of this CSS attribute as well as others that I have added after.
Ok. It looks like most of the troubles have a solution. I am a bit unclear about categories, but it seems as though they ought to follow a similar rule as the translated wiki pages. This also leads me to believe that I may need to adjust some of the auto-categorizing markup in the navigation templates.