Closed Bug 548126 Opened 14 years ago Closed 14 years ago

Have a plan to localize opentochoice.org 1.0 while 0.5 is already live

Categories

(Websites Graveyard :: opentochoice.org, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: stas, Assigned: stas)

Details

(Keywords: l12y)

All localizers are Subscribers on stage now, which means they cannot edit anything (on stage). This is because (1) new dev work has started on stage and (2) we'd like localizers to focus on the user-facing content on production.

(On production, on the other hand, the same accounts are "Localizers". This means that the localizers can edit string and posts translations on production.)

Once we're ready with 1.0 on stage to start localization, we'll change their roles to "Localizers". We'll need to figure out how exactly to move localizers between 0.5 production and 1.0 stage.

I'll comment with a draft plan shortly.
PLAN A
======

When 1.0 EN content is in SVN:

1) PROD: Remove "edit_others_pages" from the "Localizer" user role.

   * localizers will no longer be able to change string translations on production
   * but they will be able to edit posts
   * this is done to "lock" the translations before the DB dump
   * this should be OK, we have all locales 100% complete by now
   * if a change is really required, l10n-drivers change by hand, instructed by localizers

2) PROD: Dump the DB

3) STAGE: import the dump from #2

   * this will import all posts, translations and users from production

4) STAGE: re-scan the 1.0 theme files using WPML to add new strings to the WPML's "String translation" panel

5) STAGE: ADD "edit_others_pages" to the "Localizer" user role.

   * localizers can now work on the 1.0 content on stage

On March 2, when the localized version is scheduled to go live, stage will have new strings, but production will have new posts.

6) STAGE: Change all localizers to "Subscribers"

   * in order to lock the string translations on stage

7) STAGE: dump wp_icl_* tables containing string translations 

8) PROD: import the tables from the dump from #7 to the production DB.

   * production is now in sync with stage wrt to string translations

9) PROD: ADD "edit_others_pages" to the "Localizer" user role.

From now on, localizers work only on production.

Steps 7 & 8 are the tricky ones. I'll try to test this. In case it turns out this doesn't work as expected, we can export PO files from stage and import them on production. This has to be done manually for each locale, however.

What do you think?
Assignee: nobody → stas
Status: NEW → ASSIGNED
Note: this plan is for string (theme) translation. I'm still thinking how to do the proper content (blog posts) translations for 1.0.(In reply to comment #1)


> Steps 7 & 8 are the tricky ones. I'll try to test this. In case it turns out
> this doesn't work as expected, we can export PO files from stage and import
> them on production. This has to be done manually for each locale, however.

After more thinking, I'd be up for that, in fact. I don't really want to touch the DB on prod, tbh.
For posts translations, the current plan is to use the following strategy. (all happens on production)

1. We will create a tag in Wordpress called “live075” which will designate content that should be visible on the 0.75 version of the site

2. A code change in our theme will make Wordpress only display items tagged with “live075”

3. We will go through all posts that are currently live (open letter + translations) and add this tag to them.

4. Marketing team will put all 1.0 content on production, and will not use this tag.

5. Localizers will start localizing content on production, and will not use this tag.

(“Not using the tag” is easy, you basically don’t have to do anything. This means that live content for 0.75 is opt-in: it has to be explicitly tagged in order to show up on 0.75. This will help avoid accidental publishing of 1.0 content before it’s scheduled to go live.)

If there’s a post on Friday on Monday that we will want to publish on 0.75, we just need to tag it “live075”.

The 1.0 codebase will not have the piece of code which filters posts by this tag. Consequently, when 1.0 goes lives, all posts and translations will be made visible.

Let me know how this sounds.
why do you want to stick to 075 as a tag? maybe sth a bit more meaningful like "localizable" or "l10n" (of course filter out on production page tag list). That would keep it valid for such operation with the next iteration.
I think "live075" is very meaningful :) It means: this is live on 0.75. Everything else is not and waits for 1.0.
This is done now. I filed bug 548818 to follow up with points 6-9 outlined in comment 1 on March 2nd.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Websites → Websites Graveyard
You need to log in before you can comment on or make changes to this bug.