August 2010 - openSUSE Wiki - openSUSE Mailing Lists

[opensuse-wiki] pt.o.o
by Kayo Hamid 18 Aug '10

18 Aug '10

Guys, we are working to translate the new schema to our wiki, but we have some problems - We do not have some extensions like CategoryTree - Missing the Bento theme My big question is: what will happen with pt.o.o? We can continue to translate the pages without future problems? -- Kayo Hamid Fontinhas - kayohf(a)gmail.com openSUSE Member, Ambassadors & Testing Core Team http://en.opensuse.org/User:Kayohf -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

2 1

[opensuse-wiki] Performance Options
by Matthew Ehle 17 Aug '10

17 Aug '10

Hello Everyone, I was looking at some site stats, and right now Google is reporting that the wiki pages are taking an average of between 2.5 and 3.5 seconds to load. This is slower than 50%+ for all sites. I am hoping to cut this down to under 2 seconds, which would put us in the 25% range or better. Here are a couple of options to do that: Localization Caching - There is no conceivable reason to not do this, and it should provide a small speed increase. Enable Gzip - This would help out a little, and there shouldn't be much risk to it. File Caching - This would provide a major boost in speed. This alone could take nearly a second off page loading time. However, this does have a drawback. Taken from the manual page: "The file cache tends to cache aggressively; there is no set expiry date for the cached pages and pages are cached unconditionally even if they contain variables, extensions and other changeable output. Some extensions disable file cache for pages with dynamic content." How badly would this affect us? It would be easy enough to cron up a refresh of this cache if that would help. Combine external files - Perhaps some of the skin designers might want to look at this. Right now, each page requires up to 13 CSS files and 9 Javascript files, a good portion of which are on static.opensuse.org. Combining some of these would make a noticeable difference. Caching Proxy (Squid) - An alternative to file caching and a viable long term option. Would require some big changes and probably not justifiable right now... I can work on the first two, but I would like to hear some input on the last three. In particular, I want to see if the file caching option is viable, since it has the largest potential right now.

4 8

[opensuse-wiki] Templates for languages.o.o
by Matthew Ehle 17 Aug '10

17 Aug '10

Hello, I have exported all the templates from the English wiki. I was wondering if they should all be imported into languages.o.o. I think there's something like 150 of them, so it would likely save on time. Also, I have put an article on planet.opensuse.org about all that has happened with the wikis lately. Considering that we were running on MediaWiki 1.5 just a year ago, we have come a pretty long way! By the way, I will soon be trying out MediaWiki 1.16 on the Novell wikis. Provided that all goes well there, expect an upgrade to the openSUSE wikis within a month or two. This should be MUCH less painful than the jump from 1.5 to 1.15 =)

3 4

Re: [opensuse-wiki] validate email address instructions in German
by Matthew Ehle 16 Aug '10

16 Aug '10

>>>> Thomas Schmidt 08/16/10 3:53 AM >>> >On 13.08.2010 16:26, DenverD wrote: >>while looking at http://en.opensuse.org/openSUSE:Services_help just >> now i saw a new (to me) link saying to edit i need to verify my email >> address...(a feat i thought was done years ago when i received my >> novell/openSUSE ID/password login for the forum..) but i decided to >> play the new game and am directed to: >> >> http://en.opensuse.org/Help:Email_validation >> >> which includes instruction to go to >> https://secure-www.novell.com/selfreg/jsp/protected/validateEmail.jsp >> >> where i am assaulted ;-) with German text that will NOT translate to >> understandable English at google.. >> >> i don't really enjoy these games.. > >I think the Novell account pages switch to a language that is preferred by your browser. >You could check for example on http://www.ericgiguere.com/tools/http-header-viewer.html >if your browser prefers german (accept-language). In addition, there is a cookie that gives localization information, but I have no idea why that would have been set to German for you. You can test that by going to www.novell.com. On the top right of the page, there is some text that indicates country and language. Just select the button to the right ("Change"), and pick your favorite country and language. That will set the cookie to a language you can understand ;)

3 3

[opensuse-wiki] Update selected language wikis to the current state of en.opensuse.org
by Rajko M. 16 Aug '10

16 Aug '10

Bugzilla request: https://bugzilla.novell.com/show_bug.cgi?id=629405 can produce longer discussion, so it would be better to use ML for that *** Having separate wiki.o.o was advantage with en.o.o, as it helped to create new structure without having ballast of backward compatibility on our neck that can spoil efforts and final result will be far from wanted. Our biggest problem after the switch was sudden and large change, which always creates tensions. People have aversion to change. With language wikis is different. They don't have backward compatibility problem, all they have now is problem how to get in sync with en.o.o. What is advantage of just updating? 1. We don't have to think about article histories and attribution to authors, they will be preserved with article move to new location. 2. When splitting articles all we have to do is: 2.1. create new article 2.2. leave message in a very first comment that tells: "This article is based on [[original_article_name]]." The new wiki allows to use syntax [[original_article_name]] which is converted to link to original article, even in comment field. 3. Move is much faster operation then export from one wiki and import to the other, plus all icons and logos are in place and can be replaced as time permits with those that are used in en.o.o. 4. The change will be stretched over the time which will give users a chance to adjust. 5. Search engines will not index temporary wiki. (Any more?) BTW, script (bot) that will browse wikis and update interwiki links is long overdue, so this can be opportunity to find or create one. Disadvantage: 1. A lot of article deletions, which can be handled with some of scripts in a maintenance directory like deleteBatch.php , or some extension that will remove all traces of deleted files like http://www.mediawiki.org/wiki/Nuke . 2. There is need for careful planning, like listing articles in few categories: 1) keep (keep as is, split to, update) 2) obsolete good >> direct to Archive 3) obsolete and low quality >> delete 4) need expert help and probably more. Comments, please :) -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

6 11

[opensuse-wiki] validate email address instructions in German
by DenverD 16 Aug '10

16 Aug '10

while looking at http://en.opensuse.org/openSUSE:Services_help just now i saw a new (to me) link saying to edit i need to verify my email address...(a feat i thought was done years ago when i received my novell/openSUSE ID/password login for the forum..) but i decided to play the new game and am directed to: http://en.opensuse.org/Help:Email_validation which includes instruction to go to https://secure-www.novell.com/selfreg/jsp/protected/validateEmail.jsp where i am assaulted ;-) with German text that will NOT translate to understandable English at google.. </sigh> i don't really enjoy these games.. and, since i guess it might be an iChain thing, i'm not sure if i should report it to an iChain person, the wiki mail list, Henne direct, admin(a)opensuse.org, webmaster(a)opensuse.org, or to the wiki forum.. but, since i don't see this situation described on http://en.opensuse.org/openSUSE:Services_help maybe it should go to Bugzilla as an "Anything else" but, for now i'll hold off on filing a bug.. DenverD cc: Henne cc: webmaster(a)opensuse.org cc: admin(a)opensuse.org -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

2 1

Re: [opensuse-wiki] New language.o.o request
by Matthew Ehle 10 Aug '10

10 Aug '10

>> I agree that we shouldn't have two domains (wiki.o.o and en.o.o) serving >> the same content. Therefore I propose to change wiki.o.o - it should >> just RedirectPermanent to en.o.o/$requested_page. This will also make >> sure that search engines replace wiki.o.o with en.o.o in their results. > >+1 > >Can you add that to the bug report: >https://bugzilla.novell.com/show_bug.cgi?id=629542 I have just set up Apache to redirect wiki.o.o to en.o.o with a 301 status code. >> This also means that you should really create a new subdomain >> (languages.o.o or babel.o.o), even if it is more work ;-) > >+1 It actually really isn't that much work, at least not for me. It's more that I'm very big on the KISS principle, and it's just starting to feel like there are a lot of exceptions creeping in ;-) >languages.o.o is pretty obvious what it is meant and it is already requested >in a bugzilla Fair enough, but remember that Bugzilla requests can always change :P I am kind of partial to babel.o.o myself, but I agree that it is not likely to translate well to other languages or cultures. Too bad, since it seems to be such a good description of what we'll find there! In any case, I'll start the process of getting languages.o.o going tomorrow.

2 1

[opensuse-wiki] missing pages
by Ludwig Nussel 10 Aug '10

10 Aug '10

Hi, I noticed that that following pages are not available in the new wiki. Please migrate them to an appropriate place: http://old-en.opensuse.org/Security http://old-en.opensuse.org/Security_Features http://old-en.opensuse.org/Packaging/Security_Policies http://old-en.opensuse.org/Encrypted_Filesystems http://old-en.opensuse.org/SuSEfirewall2/Service_Definitions_Added_via_Pack… cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

5 7

[opensuse-wiki] rpmlint docu in wiki
by Ludwig Nussel 10 Aug '10

10 Aug '10

Hi, Is http://en.opensuse.org/openSUSE:Packaging_checks supposed to stay that way? I'm asking because I'd like to have links into the wiki for rpmlint and other build check errors. For example the web ui could link to the wiki when viewing the build log and osc could dump a list of links when viewing the log. Atm a link would look like this: http://en.opensuse.org/openSUSE:Packaging_checks#arch-dependent-file-in-usr… I'm not sure an anchor in the page scales though. It might be better to have one page per error. That also has the advantage that clicking on an error that doesn't exist yet would offer to create the page. All available rpmlint description pages could be listed in an automatically created page like this one: http://en.opensuse.org/Category:Build_Service Opinions? What's needed to make it happen? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

2 1

[opensuse-wiki] New language.o.o request
by Matthew Ehle 10 Aug '10

10 Aug '10

Hello Everyone, I know there has been some discussion on creating a language.o.o subdomain and using that as a sort of sandbox for multilingual content. Recently, bug 629542 has been submitted for it. Before I do this, may I request that we consider using our current wiki.o.o for this purpose instead of creating languages.o.o? My reasons for this are given in the bug comments, but the short of it is that I want to keep things simple, both from my standpoint and that of the users. Why have two domains serving the same content, while we create an entirely different one for new content? Also, creating a new subdomain takes time, as we need to wait for the DNS entry, iChain configuration, database setup, after which, I will need to muck around with the wiki farm configurations to accommodate a new subdomain that doesn't fit in with the pattern we have been following. Just some food for thought...

3 2