On Sun, Sep 11, 2005 at 12:33:11AM +1000, Peter Moulder wrote:

...

On Sat, Sep 10, 2005 at 06:46:25AM +0200, Daniel Stiefelmaier wrote:

...

...

I talked to bbyak and he told me, to ask here if it is possible to have a localized version of www.inkscape.org, like www.inkscape.org/de/

It would be nice if we let the browser's Language preferences determine the language shown, so that pages appear in the best language automagically. This means that people can use existing URLs, or follow a link from a news article in a different language.

I'm told inkscape.org is using apache 1.3; here are some docs:

http://httpd.apache.org/docs/1.3/content-negotiation.html

(The corresponding 2.0 page is interesting in that it uses content negotiation to choose the language, so

http://httpd.apache.org/docs/2.0/content-negotiation.html

appears in French for me.)

Mmm, I like this idea. A few thoughts though...

Having this be detected by the browser would be advantageous in that the translators would not need to alter any of the links within the site. By and large I've tried to keep all the links relative, so they should "just work" for the most part. Those that aren't relative mostly use the site_root variable so those should also work in theory. However, I think there are still going to be some exceptions here and there.

We don't have access to the Apache config file, except through SourceForge admins. I took a quick look at httpd.conf and it appears that it is configured for doing content negotiation, and mod_negotiation is loaded, although I couldn't verify that this was actually enabled for project web areas. Also, I don't know if sourceforge's apache actually runs off of shell.sf.net or some other machine, so this might not even be the right config file anyway.

I wonder if we may be able to control this through our .htaccess file. Could someone experiment with this? Log into shell.sf.net and see what you can do with this file:

/home/groups/i/in/inkscape/inkscape_web/.htaccess

Initially the translations of the website are not going to be complete, or will not always be in sync. Will it be easy for people to switch back and forth between english and their native language?

From the apache documentation, it sounds like the way to handle

translations is to have copies of the page in the same directory, but with a language extension (E.g., index.html, index.html.es, etc.) rather than having them in a subdirectory. Personally, I'd think it'd be cleaner to have the translated sites in a separate subdir, but if there's a convention for doing this, we should follow it. An advantage to having the files together is that it would be easier to spot inconsistencies. Anyway, can someone look into how translated files are traditionally stored when using apache, so we can organize the translation efforts accordingly?

Bryce

Maybe we can use the publishing script to do our "includes" for us, and go back to just using straight .html files?

That would at least stop the annoying reload of doxygen index files, if I'm not mistaken, so I'm for it.

ralf

On Sun, Sep 11, 2005 at 07:07:23AM -0500, aaron@...749... wrote:

<?php $mtime = filemtime($_SERVER['SCRIPT_FILENAME']); $gmdate_mod = gmdate('D, d M Y H:i:s', $mtime) . ' GMT'; header("Last-Modified: $gmdate_mod"); ?>

Nope, you need to actually process client headers for "If-Match" sequences, generate Etags, modtimes, etc. Craziness, but doable:

e.g.:

$hash = md5($file);

// FIXME: this header needs to change if it's not a jpeg... header("Content-type: image/jpeg");

$headers = getallheaders(); if (ereg($hash,$headers['If-None-Match'])) { header('HTTP/1.1 304 Not Modified'); } else { header("ETag: "{$hash}""); header("Last-Modified: ".gmdate("D, d M Y H:i:s", filemtime($file)) . " GMT"); header("Content-Length: ".filesize($file));

$fp = @fopen($file,"rb"); fpassthru($fp); fclose($fp); }

On Sun, Sep 11, 2005 at 07:51:35PM +1000, Peter Moulder wrote:

On Sat, Sep 10, 2005 at 10:26:46PM -0700, Kees Cook wrote:

...

_however_... we use PHP. So I have no idea how to handle that. :P Maybe we can use the publishing script to do our "includes" for us, and go back to just using straight .html files?

Offhand, the only place I can think of where we actually use PHP in a non-static way is on the front page, for the random screenshot. However, I'm unfamiliar with the wordpress stuff.

The wordpress stuff has been removed. Not enough people were using it, and I prefer doing it with static files. The one feature WP had that everyone would have missed going to static was RSS feeds, however I wrote a tool to generate RSS feeds from the static page; works like a charm, and quite lightweight. :-)

I think that we've taken advantage of PHP on some other pages just for convenience's sake. E.g., I think the screenshots page may do this. However I'd bet the same could be achieved via some clever CSS or something.

If the random screenshot on /index.php is indeed the only non-static thing we do with php, then I think we can & should generate static HTML pages ahead of time for all the other pages. People have complained about the doxygen pages in particular being dynamically generated and hence uncached. (I haven't checked whether this is still the case.)

Good points, I think you're right that if we don't really use PHP that heavily, static html could have some strong advantages.

Since we use the publish_web.sh script anyway, if there was any need for doing some processing of pages, seems like it could be added in there.

Bryce

On Fri, 2005-09-09 at 22:06 -0700, Bryce Harrington wrote:

On Sat, Sep 10, 2005 at 06:46:25AM +0200, Daniel Stiefelmaier wrote:

...

Hi Guys! :)

I talked to bbyak and he told me, to ask here if it is possible to have a localized version of www.inkscape.org, like www.inkscape.org/de/

Good, this is a good thing to do.

Having a /de/ directory would be bad because it would break any absolute paths in links. http://de.inkscape.org/ would be better.