447903 - After translating article, article appears not joined to locale

Status: VERIFIED FIXED

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

Description

[Nelson Ko [:nkoth]]

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.

Comment 1

[Nelson Ko [:nkoth]]

Attachment: 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

Comment 2

[Nelson Ko [:nkoth]]

in r17379 (trunk) and r17380 (production)

Comment 3

[Masahiko Imanaka [:marsf]]

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

[Chris Ilias [:cilias]]

(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).

Comment 5

[Masahiko Imanaka [:marsf]]

(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

Comment 6

[Masahiko Imanaka [:marsf]]

Original article.
http://support.mozilla.com/en-US/kb/Mouse+buttons+do+not+work+as+Back+and+Forward

Comment 7

[Masahiko Imanaka [:marsf]]

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

Comment 8

[Masahiko Imanaka [:marsf]]

I think this is same as bug 451509.

Comment 9

[Underpass]

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

Comment 10

[Chris Ilias [:cilias]]

Which articles?

Comment 11

[Underpass]

Now I fixed it. But they were:

http://support.mozilla.com/en-US/kb/Search+suggestions

http://support.mozilla.com/en-us/kb/Bookmarks+and+toolbar+buttons+not+working+after+upgrading

Thanks

Comment 12

[David Tenser [:djst]]

Delphine, the French localizer also got this not too long ago. This bug happens, only very rarely. Nelson, any ideas?

Comment 13

[Chris Ilias [:cilias]]

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.

Comment 14

[David Tenser [:djst]]

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?

Comment 15

[Underpass]

Another article is

http://support.mozilla.com/it/kb/Cannot+view+full+screen+Flash+videos

who does not seems joined to

http://support.mozilla.com/it/kb/Impossibile+visualizzare+contenuti+Flash+a+schermo+intero

Comment 16

[David Tenser [:djst]]

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.

Comment 17

[Nelson Ko [:nkoth]]

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.

Comment 18

[David Tenser [:djst]]

(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. :(

Comment 19

[Paul Craciunoiu [:paulc]]

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.

Comment 20

[David Tenser [:djst]]

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?

Comment 21

[Nelson Ko [:nkoth]]

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.

Comment 22

[Masahiko Imanaka [:marsf]]

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.

Comment 23

[Paul Craciunoiu [:paulc]]

Couldn't reproduce so I'm marking this as fixed. We can just reopen it if people still notice the problem.

Comment 24

[Marc Laporte]

Very hard for me to tell. It may very well be tiki_fixed, tiki_bug or sumo_only

Comment 25

[Louis-Philippe Huberdeau]

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.