Hi!
I'm planning on starting a openguide for the Buenos Aires city (Argentina). I already have a draft (http://guiaba.mine.nu/cgi-bin/openguides/og), but I have some doubts and I want to share them with you:
I'm concerned about language. I hope the guide to be used for locals and visitors, but specially for locals. So, english doesn't seem to be a good option. But: all the other pages in openguides are in english, including Oslo's; and the software doesn't seem to suppor multi-language. I'm not really convinced on using openguides as a platform, since the only features I see which gave me some advantage over other wiki engines are categories and locales (which can be implemented with some hack), and they aren't trated in a special way, it is the same if I put a link at the bottom of the page The rest of metadata doesn't seem to be used except to be shown in the same page (the coordinates system can't be used, since i'm outside the uk). Another important fact is that it is too slow withour mod_perl.. is there any provision for running under it?
I don't want to be a flamer, just those are questions that arose when starting this project (which I had in mind before knowing openguides), and may be someone can help me....
Excelente, señor!
It always was one of the aims of OpenGuides for the software to be usable everywhere on the globe. We havent gotten round to most of this yet, as the main protagonists have full time jobs. Patches are welcome however :).
See comments below.
----- Original Message ----- From: "Martín Hernán Ferrari" yo@martinferrari.com.ar To: openguides-dev@openguides.org Sent: 09 April 2004 04:17 Subject: [OpenGuides-Dev] nwe project
Hi!
I'm planning on starting a openguide for the Buenos Aires city (Argentina). I already have a draft (http://guiaba.mine.nu/cgi-bin/openguides/og), but I have some doubts and I want to share them with you:
I'm concerned about language. I hope the guide to be used for locals and visitors, but specially for locals. So, english doesn't seem to be a good option. But: all the other pages in openguides are in english, including Oslo's; and the software doesn't seem to suppor multi-language.
I don't see why you couldn't install a Spanish OpenGuides site. You will need to translate the templates. If you do this, please consider submitting the translated templates to CPAN (suggested name space OpenGuides::ES).
There might be some other issues with character sets, Lingua::Stem and Search::InvertedIndex, but I think that these would only be minor.
Having a multilingual site is a different ball game. I don't know if it's possible. I don't know how you would maintain the translated wiki text in parallel for each page.
I'm not really convinced on using openguides as a platform, since the only features I see which gave me some advantage over other wiki engines are categories and locales (which can be implemented with some hack), and they aren't trated in a special way, it is the same if I put a link at the bottom of the page
In many ways, the categories and locales are the whole point of OpenGuides. Granted, they can be done as a "hack" on other wikis - this is the history of the London OpenGuide, which started out as "Grubstreet" using the UseModWiki script.
The rest of metadata doesn't seem to be used except to be shown in the same page (the coordinates system can't be used, since i'm outside the uk).
We're working on that - coordinates. (/me needs to pull finger out).
Have you looked at the RDF syndication (format=RDF) option for each page? This enables other websites to get hold of the metadata. See http://www.livejournal.com/userinfo.bml?user=london_wiki for an example of this.
Another important fact is that it is too slow withour mod_perl.. is there any provision for running under it?
You say it is too slow. We have not had any recent complaints about responsiveness on the existing sites. If you can give an example of this slowness, please let us know.
Granted high volume sites benefit hugely from mod_perl. But, how many hits per second do you imagine getting?
In terms of running on mod_perl, possibly the underlying CGI::Wiki engine could be ported to run on Apache::Session - I'm not an expert on this, perhaps others on the list can answer this one.
I don't want to be a flamer, just those are questions that arose when starting this project (which I had in mind before knowing openguides), and may be someone can help me....
Good questions all round. Welcome to OpenGuides.
Ivor.
Hello Ivor!
Excelente, señor!
Gracias! :)
It always was one of the aims of OpenGuides for the software to be usable everywhere on the globe. We havent gotten round to most of this yet, as the main protagonists have full time jobs. Patches are welcome however :).
Hehehe, I *knew* that would be said :) Well, I'm starting to get bettar at perl programming, but by no means I'm a great programmer.. I could try, anyway...
I don't see why you couldn't install a Spanish OpenGuides site. You will need to translate the templates. If you do this, please consider submitting the translated templates to CPAN (suggested name space OpenGuides::ES).
OK.
There might be some other issues with character sets, Lingua::Stem and Search::InvertedIndex, but I think that these would only be minor.
What overwhelms me a little is the amount of libraries I have to deal with, and none of them are apt-gettable!!! :)
Having a multilingual site is a different ball game. I don't know if it's possible. I don't know how you would maintain the translated wiki text in parallel for each page.
well, it is done in wikipedia. In fact I've been trying mediawiki this days in parallel with openguides (in fact, travelwiki uses it), and I have to say it is impressive, but it is too big for a wiki and it is not easily customizable, nor good documented. Features i liked the most of it: interkwiki linking, talk, watching pages, user can logon with password (but not forced to do so).
In many ways, the categories and locales are the whole point of OpenGuides. Granted, they can be done as a "hack" on other wikis - this is the history of the London OpenGuide, which started out as "Grubstreet" using the UseModWiki script.
I see... but, the point is, I can put Location_BuenosAires or Category_Bars at the end of the page (like c2 does) and then use search referring pages, and it is almos the same. Since locales in openguides doesn't show all pages in the locale by default.
The rest of metadata doesn't seem to be used except to be shown in the
same
page (the coordinates system can't be used, since i'm outside the uk).
We're working on that - coordinates. (/me needs to pull finger out).
uh.. I don't know what to pull a finger out is... my crappy english :)
Have you looked at the RDF syndication (format=RDF) option for each page? This enables other websites to get hold of the metadata. See http://www.livejournal.com/userinfo.bml?user=london_wiki for an example of this.
well, I'd never given any look at rdf and syndication :) I'm looking at it right now... But i don't see any metadata used at all, just a changelog.. Sorry, but I don't know anything about rdf :)
You say it is too slow. We have not had any recent complaints about responsiveness on the existing sites. If you can give an example of this slowness, please let us know.
Click on my draft site :) The computer is a k6-500 and it is very slow there, i think compilation times are killing it...
Granted high volume sites benefit hugely from mod_perl. But, how many hits per second do you imagine getting?
no, it is not what worries me, just waiting 7 seconds for each page (at localhost) seems a bit too much for me :)
In terms of running on mod_perl, possibly the underlying CGI::Wiki engine could be ported to run on Apache::Session - I'm not an expert on this, perhaps others on the list can answer this one.
Well, I have a experience porting a small application to mod_perl in my day job and it hasn't been easy :( But I think the task should not be to port the engine but the front end. If you already have all the logic in a .pm well done, the porting is easy, you just change the way the underlying modules are called...
Good questions all round. Welcome to OpenGuides.
Thanks!! I want to say that if I'm saying all these things is because I like openguides, and maybe my worries are because I'm just missing :)
Hi, I'm based in Goa-India and am a journalist here. Since I believe and use Free Software, I am also strongly committed to putting out my information in a non-copyright encumbered format.
Some of my photos on Goa are already online -- available for free download. See http://www.goa-world.net/fotofolio
I have written a text to some parts of South Goa (including Canacona, a newish destination which has a lot of popularity among tourists). I'd like to put it out on OpenGuides, but don't have easy access to the Net, nor the required skills to deal with the software used. Could someone help me with putting up the content on OpenGuides, if I send it across? Am also open to writing more chapters dealing with Goa. FN
I reply to this slightly old message to let you know that I am planning an OpenGuide site for my hometown of Bologna, Italy.
I am going down the route of our Argentinian friend for a local-language site (i.e. in Italian), so same questions apply here too.
My test site is at http://www.alessio.sevenseas.org/bologna/ it will most likely be published as http://www.openguide.bologna.it/ (yet to be registered).
On Fri, 2004-04-09 at 14:12, IvorW wrote:
I don't see why you couldn't install a Spanish OpenGuides site. You will need to translate the templates. If you do this, please consider submitting the translated templates to CPAN (suggested name space OpenGuides::ES).
I am translating right now and I will definitevely upload OpenGuides::IT, unless there is some other Italian on the list working on a similar project.
We're working on that - coordinates. (/me needs to pull finger out).
Thanks, that would have been my first question. But I see some site (US?) are already running with "standard" coordinates. More info on this?
On Tue, Jun 08, 2004 at 03:35:53PM +0200, Alessio Bragadini wrote:
I reply to this slightly old message to let you know that I am planning an OpenGuide site for my hometown of Bologna, Italy.
I am going down the route of our Argentinian friend for a local-language site (i.e. in Italian), so same questions apply here too.
My test site is at http://www.alessio.sevenseas.org/bologna/ it will most likely be published as http://www.openguide.bologna.it/ (yet to be registered).
Hmm. Has anyone been thinking about internationalizing the templates yet? I assume the non-English language sites are currently doing this by hand-hacking them?
I wouldn't mind overseeing this.
Cheers,
Dominic.
Ciao Alessio,
On Tue, Jun 08, 2004 at 03:35:53PM +0200, Alessio Bragadini wrote:
I reply to this slightly old message to let you know that I am planning an OpenGuide site for my hometown of Bologna, Italy.
That's great to hear!
I am going down the route of our Argentinian friend for a local-language site (i.e. in Italian), so same questions apply here too.
Right; any feedback you can give us about that process would be much appreciated. My thoughts on the matter at the moment are that we need a meta-template with all the English strings in the project that will be easy to edit and localise (and, hopefully, be submitted back to us to include with the project when completed).
I really do like the sound of Italian. Everybody should get themselves a "Buona educazione Wiki"!
it will most likely be published as http://www.openguide.bologna.it/ (yet to be registered).
I'd be quite happy to set you up bologna.openguides.org as a CNAME or A record, if you like, so you wouldn't need to register anything.
Good luck!
Earle.
On Tue, 2004-06-08 at 10:35, Alessio Bragadini wrote:
I am going down the route of our Argentinian friend for a local-language site (i.e. in Italian), so same questions apply here too.
I was thinking about this issue, and to me seems to have two possible approaches:
1. To treat the templates entirely as user configuration, nobody will use them as bundled, because we all want to have our own look&feel. So, language will just be part of this config thing, and OG should only give different default templates for different languages. This doesn't solve any multi-language issues.
2. To separate look&feel from strings and some logic inside the templates. Look&feel would be config (css + structure), and the strings could be managed in two ways: language templates, defining variables (the templating system is *very* powerful); and using gettext (standard way, but more hacky to implement here)
Just my 2 pesos :-)
On Wed 09 Jun 2004, Mart?n Ferrari yo@martinferrari.com.ar wrote:
- To treat the templates entirely as user configuration, nobody will
use them as bundled, because we all want to have our own look&feel.
I'm not happy about people using anything other than the templates in the distro, since they still have some application logic in them. We have had bugs in the templates; I'm sure there are still some lurking. Using custom templates is very much done at your own risk.
- To separate look&feel from strings and some logic inside the
templates. Look&feel would be config (css + structure), and the strings could be managed in two ways: language templates, defining variables (the templating system is *very* powerful); and using gettext (standard way, but more hacky to implement here)
Locale::Maketext looks interesting: http://search.cpan.org/~sburke/Locale-Maketext/
Kake
On Thu, Jun 10, 2004 at 01:14:26PM +0100, Kate L Pugh wrote:
On Wed 09 Jun 2004, Mart?n Ferrari yo@martinferrari.com.ar wrote:
- To treat the templates entirely as user configuration, nobody will
use them as bundled, because we all want to have our own look&feel.
I'm not happy about people using anything other than the templates in the distro, since they still have some application logic in them. We have had bugs in the templates; I'm sure there are still some lurking. Using custom templates is very much done at your own risk.
But it is trivially obvious that people /do/ want to be able to edit them willy-nilly, and so they should. We shouldn't be enforcing a particular look and feel unnecessarily, so anything we can do to ease maintainance of custom template hacks is a good thing. For example, more splitting up of the logic in the templates; an install/upgrade system that will detect changes made to the templates in a dpkg-like way that will prompt you to decide whether you want to keep the locally-modified version or use a new distributed file.
- To separate look&feel from strings and some logic inside the
templates. Look&feel would be config (css + structure), and the strings could be managed in two ways: language templates, defining variables (the templating system is *very* powerful); and using gettext (standard way, but more hacky to implement here)
Locale::Maketext looks interesting: http://search.cpan.org/~sburke/Locale-Maketext/
It's certainly a step in the right direction but it only deals with string replacement and it's not a complete solution to the above.
Dominic.
On Thu 10 Jun 2004, Dominic Hargreaves dom@earth.li wrote:
But it is trivially obvious that people /do/ want to be able to edit them willy-nilly, and so they should. We shouldn't be enforcing a particular look and feel unnecessarily, so anything we can do to ease maintainance of custom template hacks is a good thing. For example, more splitting up of the logic in the templates; an install/upgrade system that will detect changes made to the templates in a dpkg-like way that will prompt you to decide whether you want to keep the locally-modified version or use a new distributed file.
Agreed.
Kake
On Thu, Jun 10, 2004 at 01:14:26PM +0100, Kate L Pugh wrote:
On Wed 09 Jun 2004, Mart?n Ferrari yo@martinferrari.com.ar wrote:
- To treat the templates entirely as user configuration, nobody will
use them as bundled, because we all want to have our own look&feel.
I'm not happy about people using anything other than the templates in the distro, since they still have some application logic in them. We have had bugs in the templates; I'm sure there are still some lurking. Using custom templates is very much done at your own risk.
Changing the templates is not for the faint hearted, http://www.iloveni.com has some fairly extensive changes in there but I had a couple of good reasons: the coordinate system doesn't yet work for Ireland so I removed some functionality for the time being and I wanted accessible XHTML rather than HTML, which means changing a few things.
But in my opinion you as developers should not really think about look and feel and just supply building blocks for others to create 'flavours' of OpenGuides. I think if you separated engineering from design and created two projects you'd get a better product.
Stephen
On Tue, 2004-06-08 at 15:49, Dominic Hargreaves wrote:
Hmm. Has anyone been thinking about internationalizing the templates yet? I assume the non-English language sites are currently doing this by hand-hacking them?
I have mixed-opinions about this. First of all, the templates *are* going to be changed, this is normal in building a separate website, and it may also be necessary in the process of moving to a different language/culture. So while it may be a good idea to provide stock templates in different languages, I very much doubt that this is going to be the end of the story.
I actually planned to do this using a CVS repository, storing OG releases on the "vendor branch", working for my Italian templates on the main trunk and merging new releases as they appear. This is similar to the work I've done with friend to translate Slash (the slashdot.org CMS engine, and another Template Toolkit project) into Italian.
For a simple software like OG based on templates, I'd suspect that a full-blown localisation layer like Locale::Maketext will just add too much overhead and users will write their own text in place of the template strings. My idea is to supply more than one set of templates so users can choose their base language, and after that they have to take care of upgrades to their existing installation.
Multi-language sites are a different story and I don't see them happening soon IMHO.
On Thu 10 Jun 2004, Alessio Bragadini alessio@sevenseas.org wrote:
I actually planned to do this using a CVS repository, storing OG releases on the "vendor branch", working for my Italian templates on the main trunk and merging new releases as they appear. This is similar to the work I've done with friend to translate Slash (the slashdot.org CMS engine, and another Template Toolkit project) into Italian.
That's an interesting idea!
As a side note, I've just fixed (in CVS) yet another template bug which was stopping the map link being displayed on nodes with no address data. I'm not just being obstructive when I say that I'm concerned about people not using the distributed templates. And that was display logic, not application logic, so we *can't* get it out of the template.
Kake
On Thu, 2004-06-10 at 09:14, Kate L Pugh wrote:
On Wed 09 Jun 2004, Mart?n Ferrari yo@martinferrari.com.ar wrote:
- To treat the templates entirely as user configuration, nobody will
use them as bundled, because we all want to have our own look&feel.
I'm not happy about people using anything other than the templates in the distro, since they still have some application logic in them. We have had bugs in the templates; I'm sure there are still some lurking. Using custom templates is very much done at your own risk.
Well, I think you will agree that -even in english speaking sites- is always neccessary to customize the templates. If there is danger because of the templates having logic, the logic thing would be to isolate that logic.
- To separate look&feel from strings and some logic inside the
templates. Look&feel would be config (css + structure), and the strings could be managed in two ways: language templates, defining variables (the templating system is *very* powerful); and using gettext (standard way, but more hacky to implement here)
Locale::Maketext looks interesting: http://search.cpan.org/~sburke/Locale-Maketext/
I have just read the Locale::Maketext doc, and I think it would be too complicated just for webpage translation...
One idea: the templates system allows for inclusion, branching and variable defining, so we can select the language at the start and then load language-specific files which define variables then replaced in the look&feel templates.
On Thu 10 Jun 2004, Mart?n Ferrari yo@martinferrari.com.ar wrote:
Well, I think you will agree that -even in english speaking sites- is always neccessary to customize the templates.
Maybe. The thinking behind the CSS-related work we did a while ago was to reduce and preferably remove the need to customise the templates.
If there is danger because of the templates having logic, the logic thing would be to isolate that logic.
Indeed, and in an ideal world this would no doubt be possible. However we do not live in an ideal world. Getting application logic out of the templates is something we should be trying to do. Getting presentation logic out is impossible.
One thing we could consider is making a clear distinction between "templates you may edit without fear" and "templates you should not touch", and embedding the latter in the former using TT INCLUDEs.
One idea: the templates system allows for inclusion, branching and variable defining, so we can select the language at the start and then load language-specific files which define variables then replaced in the look&feel templates.
This kind of idea, yes.
Kake
On Thu, 2004-06-10 at 21:50, Kate L Pugh wrote:
One thing we could consider is making a clear distinction between "templates you may edit without fear" and "templates you should not touch", and embedding the latter in the former using TT INCLUDEs.
That would be wise. Like in 'full-page templates' versus 'template snippets'.
On Thu 10 Jun 2004, Kate L Pugh kake@earth.li wrote:
One thing we could consider is making a clear distinction between "templates you may edit without fear" and "templates you should not touch", and embedding the latter in the former using TT INCLUDEs.
Have made a start on this in OpenGuides 0.41, just released. See the CUSTOMISATION file in the distribution.
Kake
openguides-dev@lists.openguides.org
-
Alessio Bragadini -
Dominic Hargreaves -
Earle Martin -
Frederick Noronha (FN) -
IvorW -
Kake L Pugh -
Kate L Pugh
-
Martín Ferrari -
Martín Hernán Ferrari
-
Stephen Stewart