Closed Bug 447903 Opened 12 years ago Closed 11 years ago

After translating article, article appears not joined to locale

Categories

(support.mozilla.org :: Knowledge Base Software, task, major)

task
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: nkoth, Assigned: paulc)

Details

(Whiteboard: tiki_bug, sumo_verify)

Attachments

(1 file)

As reported in https://bugzilla.mozilla.org/show_bug.cgi?id=442690#c8, but does not belong there as it is a separate issue:

Translated article doesn't join to my locale (ja).

1. Click "Translate this page"
2. Translate and save as staging.
3. The page has saved, but does not join to my locale.
  There is no locale chenge link appears in the bottom right of the page.
  So, I have to join the article to my locale manually.
4. Click history link and select my locale at the bottom of history list.
5. Click "Update Translation" button and set locale.
6. From english page, click "Translate this page" again, then add my translated
page as this article's translation.
There are actually 2 problems leading to the reported behavior:

1) Replication lag leading to article linking not apparent.

2) After saving an article, user should see the article saved in the language of the article, not locale. To do this bl=n is required but this was not preserved before on locale detection redirects
Attachment #331245 - Flags: review?(laura)
Attachment #331245 - Flags: review?(laura) → review+
in r17379 (trunk) and r17380 (production)
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: push-needed
Resolution: --- → FIXED
I've translated a new article few minutes ago, but it does not still join to locale.
No error occured, and "?bl=n" has added to url after saving the article to staging.
So, I followed again #0 process.

The article is this.
http://support.mozilla.com/ja/kb/ツールバーをカスタマイズする方法

Any help?
(In reply to comment #3)
> I've translated a new article few minutes ago, but it does not still join to
> locale.
> No error occured, and "?bl=n" has added to url after saving the article to
> staging.
> So, I followed again #0 process.
> 
> The article is this.
> http://support.mozilla.com/ja/kb/ツールバーをカスタマイズする方法
> 
> Any help?

Works fine here. If I go to the URL above, English is in the language drop-down menu. If I switch to English, the Japanese translation is in the drop-down menu.

Were you logged in, when testing this? Articles in the staging area are not available to people not logged in.

"bl=n" is "Browser Language = no", which disables the locale fallback (bug 398353).
(In reply to comment #4)
> Works fine here. If I go to the URL above, English is in the language drop-down
> menu. If I switch to English, the Japanese translation is in the drop-down
> menu.

Because, I have manually added to ja locale immediately.
The article was needed some people.
Sorry for inconvenience.

I have translated other article.  This one that I clicked from "Translate this page" link and just saved as staging.
http://support.mozilla.com/ja/kb/マウスボタンで戻ると進むの操作ができない?bl=n
This bug has NOT FIXED today.
Please reopen.

translated (just orphaned):
http://support.mozilla.com/ja/kb/フォームの自動補完?bl=n

original (not linked to ja article):
http://support.mozilla.com/en-US/kb/Form+autocomplete?bl=n
I think this is same as bug 451509.
Just a note: this bug doesn't seem to be fixed.

Got the same problem today with the last two articles left out of "the magnificent 15". ;-)

Maybe it should be reopened.

Bye.

Simon
Which articles?
Delphine, the French localizer also got this not too long ago. This bug happens, only very rarely. Nelson, any ideas?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 0.6.1 → 0.8
Simone set me this:
<http://support.mozilla.com/it/kb/Informazioni+sul+plugin+Shockwave>, which is a translation of <http://support.mozilla.com/en-US/kb/Using+the+Shockwave+plugin+with+Firefox>.

Here's the interesting part: If I go to <http://support.mozilla.com/en-US/kb/Informazioni+sul+plugin+Shockwave>, it /does/ fall back to Using+the+Shockwave+plugin+with+Firefox.
Yes, I think I remember this being explained by Nelson once: in this case the Italian article _is_ connected to the English article, but the English article doesn't know about the Italian article. Which seems bizarre if you were to design the db in a normalized form.

Nelson, any new insights on why this is happening?
This is indeed a major bug. I even detected Swedish localizations that were completely lost because of this bug. What is the cause of it? I can't reproduce on staging server.
Severity: normal → major
If it only happens now and then (especially if on production and not staging), one possibility might be that it has something to do with db replication delay.
(In reply to comment #17)
> If it only happens now and then (especially if on production and not staging),
> one possibility might be that it has something to do with db replication delay.

Wasn't that the original suspected cause as well? Assuming that's true, what can we do about it? This bug, along with bug 451509, is hurting the l10n experience on SUMO, potentially scaring localizers off. :(
After some testing, it appears that TikiWiki identifies pages by their title only.

Go to:
http://support-stage/tiki-edit_translation.php?locale=en-US&detach&page=Firefox%20will%20not%20start&id=75&srcId=3364&type=wiki+page
... This shows the "Manage existing translations of this page" list as links of the form:
http://support-stage.mozilla.org/en-US/kb/[Page title in different languages]

This is clearly wrong. Looking at the MySQL db structure, the pageName column in tiki_pages has the UNIQUE attribute, which is not the best way to do this. The way it should work is with a composite key - title + locale - and the links constructed as "existing translations" should be /locale/kb/[Page title] instead.

Does anyone know if they fixed any of this in the next version?
It's doubtful that we can get it to work for 0.8, but I'd like to take on the job of getting it in asap. What do others think?

It seems that this requires a significant rewrite of the way storing localized pages and linking them together works.
Paul, excellent research here. Nelson, do you know if this is planned or fixed upstream? If not, what's the best approach to get this fixed asap?
Paul,

I'm not convinced that those links are /en-US/kb/..... is the problem.  /en-US/kb/[french page title] is a valid reference to a French page, since the locale refers to the locale of the user, not that of the page. 

Going to composite keys in tiki_pages is a major rewrite that will lead to months of work for a future version of Tikiwiki, so that will have to wait.

The translation sets are stored in tiki_translated_objects. This is the core of the joining mechanism. Can you do some testing and see how the translation sets in that db table holds up?

As for the links themselves, the way /locale/kb/[Page title] is handled based on the setting of the bl parameter (the best language parameter), and the user's locale. So that when bl=y, it will serve the page in the translation set in the user's preferred language if possible, and if bl=n, it will serve the page itself, regardless of the user's locale. For SUMO, we have it hardwired to have bl=y, except where bl=n is set explicitly in the query string. To make a link /non_french_locale/kb/[french_page_title] open a french page where "non_french_locale" version exists, the link should have bl=n appended to the query string. Otherwise, the "non_french_locale" version will be served.
Assignee: nelson → paul.craciunoiu
Keywords: push-needed
Target Milestone: 0.8 → 0.9
This bug has been fixed due to the bug 451509 was fixed on sumo 0.8.
New translated articles are joined to its locale today!

Thank you.
Couldn't reproduce so I'm marking this as fixed. We can just reopen it if people still notice the problem.
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → FIXED
Target Milestone: 0.9 → 0.8.2
Status: RESOLVED → VERIFIED
Whiteboard: tiki_triage (replication related?)
Very hard for me to tell. It may very well be tiki_fixed, tiki_bug or sumo_only
Whiteboard: tiki_triage (replication related?) → sumo_triage (replication related?) (see comment 24)
Whiteboard: sumo_triage (replication related?) (see comment 24) → tiki_bug
This one appears to be hard to reproduce because of the replication issues. I would simply try to see if it still applies when updating SUMO to 5.x and see what happens from there.

We had several improvements made to the multilingual handling.
Whiteboard: tiki_bug → tiki_bug, tiki_discuss
Whiteboard: tiki_bug, tiki_discuss → tiki_bug
Whiteboard: tiki_bug → tiki_bug, sumo_verify
You need to log in before you can comment on or make changes to this bug.