Hi all,
pistoncito asked about how to do translations of the website currently. I figure this suggests we need some sort of documentation, so here's a start. It sounds like we will need to change this process once we figure out how to do the automatic web browser language detection, but until that gets sorted out, we should use this process. I'll also post this to Wiki so folks can update it as better approaches are worked out for it.
http://wiki.inkscape.org/cgi-bin/wiki.pl?WebsiteEditing
Translating the Inkscape Website ================================ 1. Do a CVS checkout of the website module.
2. Create a subdirectory at the top level with your language code. I.e.:
inkscape_web/es/
3. Copy pages from the main site into your subdir structure, and begin translating them. Look in the other translated areas for examples of what needs translated.
Note: The tutorial translations in the doc/ directory are handled separately from the website translation. These are the files in inkscape_web/doc/*/ that have .XX.html extensions. You do not need to do anything about these pages.
Note: The translation of doxygen, wiki, and the various SF pages are separate from the website translation. You do not need to do anything about these pages.
4. Add a flag for your language in the images directory. It should be named inkscape_web/images/flag-XX.png. (where XX is your language code).
Next add an img for the flag to inkscape_web/includes/header.php See how the other flags are done in that file as an example.
5. Add a news item to the index page announcing your translation. You are encouraged to write it in both English and your native language.
6. If you have CVS access, then commit your changes to the site. See the Website Editing and Working With CVS documentation for directions.
If you do not have CVS access, then show your translation to one of the Inkscape administrators for review. They will then give you access to CVS and the website, so you can deploy your changes.
Bryce
On Mon, Sep 12, 2005 at 01:17:23PM -0700, Bryce Harrington wrote:
Hi all,
pistoncito asked about how to do translations of the website currently. I figure this suggests we need some sort of documentation, so here's a start. It sounds like we will need to change this process once we figure out how to do the automatic web browser language detection, but until that gets sorted out, we should use this process. I'll also post this to Wiki so folks can update it as better approaches are worked out for it.
http://wiki.inkscape.org/cgi-bin/wiki.pl?WebsiteEditing
I've also added the following note regarding a change we may make to the process in the future, once someone has sorted out the mechanisms for doing it:
Browser language autodection. Instead of placing pages in a language code subdir, you would place the files in the same directory, but set the filename to include the language code. For example:
inkscape_web/mailing_lists.html mailing_lists.de.html mailing_lists.es.html doc/index.html index.de.html index.es.html
TODO: This requires us to ensure the webserver is properly configured to properly detect the filenames correctly. It is not yet known if this works already, or would require some changes to .htaccess, or what. Someone should research this. E.g., should they be named index.XX.html or index.html.XX ?
When this is ready, the pages in the XX/ dirs should be move into the main dirs and renamed to index.XX.html, etc.
Hi all,
i think i should share my thoughts about this discussion :)
I like the idea of xx.inkscape.org, but i guess it needs some administrative effort. /xx/ has the advantage, that relative links can be used. (i just replaced $root="" with $root="../" and the links work) For subdomains, we would need to copy all files to all domains, or use full-length-paths for all the images and stuff... also, multi-subdomains are harder to test on local webservers.
That .php.xx thing sounds also good, but it has disatvantages: I (and surely others, too) don't want to be bound to one language. I could change the preferences of my browser each time i want to see another language or use two browsers, but hey, come on...
On my website caligamedia.de i did it using php. Thats more flexible. (hopefully you forget that go-back-to-static quickly ;) )
<?PHP $UA_LANGUAGE = $_SERVER['HTTP_ACCEPT_LANGUAGE'];
if($HTTP_GET_VARS['lang'] == 'de') $language = 'de'; elseif($HTTP_GET_VARS['lang'] == 'en') $language = 'en'; elseif(substr($UA_LANGUAGE, 0, 2) == 'de') $language = 'de'; else $language = 'en';
include($root.'addons/global_const.inc'); ?>
What does it? It checks, if there is something like ...index.php?lang=de in the URL (this is set by clicking my well-known flags ;) ) if this is NOT set, it checks what language is preferred by the browser. If the preferred language is not available, it defaults to english. This means: auto-language by default, user language if desired, english if these fail.
the pages themselves have no texts in it, only layout. long texts are in include-files, single words, like menu entries, in constants, defined in global_const.inc
if you like this idea, too, i'll do it... This needs neither /xx/ nor xx.inkscape.org, as its all in the same file. because i need to change all the inter-site-links. i need to add something like <?php echo "?lang=$lang" ?> to all of them, so that the chosen language remains on page changes.
The links should be updated anyway, as they need a similar postfix for the CSS setting, which is turned off on each page-change. If done this way, the links of the flags can be easily set to point to the current page instead of the main page.
hmm... as i think about it... i guess this would also be a solution to the problem, that new news do not automatically appear on /xx/ pages. with the above way, there could be some code that checks if news-yyyymmdd-01.xx.inc does exist, and, if not use news-yyyymmdd-01.EN.inc instead.
Okay, that were my... 2 or 3 euro cents :)
Greetings, Daniel
Bryce Harrington wrote:
Hi all,
pistoncito asked about how to do translations of the website currently. I figure this suggests we need some sort of documentation, so here's a start. It sounds like we will need to change this process once we figure out how to do the automatic web browser language detection, but until that gets sorted out, we should use this process. I'll also post this to Wiki so folks can update it as better approaches are worked out for it.
http://wiki.inkscape.org/cgi-bin/wiki.pl?WebsiteEditing
I see here a problem on how the translated pages will be kept up to date with the original ones. The website is live, it can be changed anytime by a lot of people, is very hard for translators to monitor such changes (especially is the changes are minor, like adding a screenshot) and also hard to manually find the modified section and add/update the translation for it.
As Alexandre said, using gettext is a better solution for maintaining translations for the website, but the effort to implement it is big enough and I doubt is worth it.
Personally, if I had to choose between an up to date English website and an old and dusty translation in my native language I would not hesitate one second and use the English one. This is why I don't think browser language detection and automatic redirection is a good idea at all if we are not sure the translated websites are complete and up to date.
note: take this with a grain of salt, I am not a big fan of translations, even change the Google page from Romanian (I guess it detect my geographic location based on IP) back to English
participants (3)
-
Bryce Harrington -
Daniel Stiefelmaier -
Nicu Buculei