After translating article, article appears not joined to locale

VERIFIED FIXED in 0.8.2

Status

support.mozilla.org
Knowledge Base Software
--
major
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: nkoth, Assigned: paulc)

Tracking

unspecified
0.8.2

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tiki_bug, sumo_verify)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
Created attachment 331245 [details] [diff] [review]
handle replication lag better, and preserve bl=n on locale detection redirects

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)

Updated

10 years ago
Attachment #331245 - Flags: review?(laura) → review+
(Reporter)

Comment 2

10 years ago
in r17379 (trunk) and r17380 (production)
Status: NEW → RESOLVED
Last Resolved: 10 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?

Comment 4

10 years ago
(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.

Comment 9

9 years ago
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
(Reporter)

Comment 17

9 years ago
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. :(
(Assignee)

Comment 19

9 years ago
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?
(Reporter)

Comment 21

9 years ago
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.
(Assignee)

Comment 23

9 years ago
Couldn't reproduce so I'm marking this as fixed. We can just reopen it if people still notice the problem.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Target Milestone: 0.9 → 0.8.2
Status: RESOLVED → VERIFIED

Updated

9 years ago
Whiteboard: tiki_triage (replication related?)

Comment 24

9 years ago
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)

Updated

8 years ago
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
(Assignee)

Updated

8 years ago
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.