Closed Bug 564069 Opened 14 years ago Closed 13 years ago

Internationalize the Student Reps website

Categories

(Websites :: studentreps.mozilla.org, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sethb, Assigned: sethb)

References

Details

Attachments

(2 files)

This patch "gettext-ifies" the Student Reps website.  The patch attempts to do the following:

1.  Wraps all localizable strings with gettext functions
2.  Setup directory layout with locale hierarchy
3.  Adds the maintenance scripts to extract and compile

Looking for a review from Stas.
Attachment #443760 - Flags: review?(stas)
Blocks: 564065
Blocks: 564073
Assignee: nobody → sethb
Blocks: 564077
Upon running the patch I found a few minor errors, just some missing "?>"s and unescaped apostrophes, that sort of thing, nothing that can't be easily fixed post-patch. I've done that locally but I'm in a holding pattern while this is still pending review. If I get a thumbs up I'll commit the gettextification and we can move on.
The patch applies fine for me, you probably forgot the hierarchy parameters:
patch -p0 -u < i18nStudentReps.patch
(In reply to comment #2)
> The patch applies fine for me, you probably forgot the hierarchy parameters:
> patch -p0 -u < i18nStudentReps.patch

The patch runs successfully, the bugs are in the code itself. You won't be able to load some pages without fixing them first. There are a few missing ?>s, one unescaped ', one missing = after a <?, and I think there was a missing ( somewhere as well. All tiny things and nothing obvious until you try to browse the site after running the patch and find blank whiteness.
ah, I misread your previous message sorry, by errors you meant errors in the code not errors in applying the patch :)

Also, the patch is calling a php file that is not included in the patch (require_once('inc/locales.php')).
Not surprised that I missed a few escaped apostrophes and ?>.  I switched code editors midway through the process because Eclipse didn't have line-wrap.

Attaching lcoales.php for you now.
Attachment #444187 - Flags: feedback?(pascalc)
Attachment #444187 - Attachment mime type: application/x-httpd-php → text/plain
Attachment #444187 - Flags: feedback?(pascalc) → feedback+
Attachment #443760 - Flags: review?(stas)
I rewrote the site to make it localizable and set up a french version with a few strings translated for testing, I used Seth's work and corrected all the errors I could find (a few forgotten strings and some strings that could be merged).

I think stas can review the new site directly from svn as it is now, another pair of eyeballs doesn't hurt :)
Awesome.  Thanks, Pascal!
I took a look at the "new" site in SVN and it seems like Pascal did, as mentioned, rewrite the entire site.  Since Craig and Pascal were working together on Friday night in #Europe, I guess I am wondering what Pascal/Craig hoped to achieve with the complete rewrite.  

Can you articulate why you did this?

My biggest concern with this new rewrite is that adding a new locale (and many more going forward) seems like it will now be very difficult because we'll need to add so many individual files to make the site work.  Have we ever done this in the recent past on other projects?  I cannot remember doing that.  The way I had it structured seemed to be exactly how we have done for Mozilla sites in the past.
(In reply to comment #8)
> I took a look at the "new" site in SVN and it seems like Pascal did, as
> mentioned, rewrite the entire site.  Since Craig and Pascal were working
> together on Friday night in #Europe, I guess I am wondering what Pascal/Craig
> hoped to achieve with the complete rewrite.  
> 
> Can you articulate why you did this?

This is well over my head, of course, but it does seem more complicated than it probably needs to be. Maybe Pascal can explain his approach and why it's the best way to go. If there's a simpler way to do it that will be cleaner and easier to maintain in the future, I'll vote for simplicity every time.
Because the previous version did not allow localization / locale detection / 404 handling with locale detection / having a locale switcher / rtl support (all this with unique urls for SEO and linking). 

This new version actually has a much cleaner code with basic templates that allow more flexibility for localization. Craig, you will find your pages in the content/ folder and see that almost nothing has changed for them except header/footer which are now in a global template so as not to have to edit several files for a code change in header/footer.

And adding a locale now is a 10 seconds work by running these commands in a script (let's call it addlocale.sh):

#!/bin/bash
svn copy ../fr ../$1
svn mkdir $2
svn mkdir $2/LC_MESSAGES/
#rm templates/LC_MESSAGES/messages.pot
#./extract-po.sh
msginit --locale=$2.utf8 --input=templates/LC_MESSAGES/messages.pot --output=$2/LC_MESSAGES/messages.po --no-translator


example of use for German:
./addlocale.sh de de_DE

1st parameter is the mozilla locale code, second is the gettext one. Done.
Awesome, Pascal.  Thanks!
BTW Craig, if you need explanations about the code changes, I am on IRC :)
(In reply to comment #10)
> Because the previous version did not allow localization / locale detection /
> 404 handling with locale detection / having a locale switcher / rtl support
> (all this with unique urls for SEO and linking). 

I might be wrong, but looking at Craig's code from last week, I think it was easily adaptable to do all this. Craig went for htaccess rewrite rules, and adding to it would have allowed to pass a locale parameter to the scripts in form of a pretty URL. For instance:

RewriteRule ^([A-Za-z--]+)/(.*) $2\.php?locale=$1 [L]

Without a rule like the one above, we effectively need to create directories and files (even if almost empty) for every locale, which doesn't look like a good solution.

> svn copy ../fr ../$1

Any advantages of doing this for this website? Are we going to have different content for different locales?
Here's some changes I worked on today:

I improved the compile-mo.sh a bit to make it safer to run via cron: http://viewvc.svn.mozilla.org/vc/projects/studentreps/trunk/locales/compile-mo.sh?revision=67056&view=markup. Bug 564065 is tracking setting it up.

I added an add_locale.sh script based on Pascal's comment 10:
http://viewvc.svn.mozilla.org/vc/projects/studentreps/trunk/locales/add_locale.sh?revision=67065&view=markup (with some modifications)

I added de, pl, es, it locales.

I changed locales/fr_FR to locales/fr to match the code that we use in Verbatim.

And I added all 5 locales to Verbatim: http://localize.mozilla.org/projects/studentreps/.

I think we're almost done :)
> RewriteRule ^([A-Za-z--]+)/(.*) $2\.php?locale=$1 [L]

passing a lang parameter and hiding it via url_rewriting is really hackish, it is also not free CPU wise and means an extra server cost on Apache for all page loads while server space (and we are talking about a few kilobytes ;) ) is really free in our infrastructure and plugs easily into our global file caching system.

>> svn copy ../fr ../$1
>Any advantages of doing this for this website? Are we going to have different
content for different locales?

Today no, but what about next semester ? And what if a locale asks for specific pages or page adaptations, or if we create new English pages that will not have to be localized? I prefer the site to be easily expandible from the start than having to redo all the work next year or to periodically tweak it to add new features. Note that we can put a symlink as  well if you are concerned about having too many files and put a real folder only if the site gets really localized and not only translated.
website was released a long time ago and is multilingual, marking fixed
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: