Closed Bug 451509 Opened 16 years ago Closed 16 years ago

Articles with unknown language

Categories

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

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cilias, Assigned: paulc)

References

(
URL
)

Details

(Whiteboard: tiki_test)

Attachments

(3 files)

Translation Step 1
40.78 KB, image/png
Details
Translation Step 2
46.24 KB, image/png
Details
Translation Step 3
47.89 KB, image/png
Details 
Probably because of bug 435148, we're starting to get articles that are not assigned to a language. It looks as though these are newly created articles; so I assume it's because the language selector is not there, when creating the article. I have yet to test that assumption.
So if people can't select the language, what's the desired behavior here?
They should be able to set the language if the page does not exit yet; and not be able to change the language afterward.
Didn't quite get to this, targeting to 0.6.4
Assignee: nobody → laura
Target Milestone: 0.6.3 → 0.6.4
Target Milestone: 0.6.4 → 0.7
Target Milestone: 0.7 → 0.8
-->0.7.1
-->Major

Currently *278 articles without a language*. I'll contact locale leaders, to go through these; but as you can see, this is affecting a huge amount of articles, and makes it very hard to track translations.
<http://support.mozilla.com/tiki-listpages.php?locale=en-US&offset=0&sort_mode=lang_asc&maxRecords=278>
Severity: normal → major
Target Milestone: 0.8 → 0.7.1
Surely you already know, but this is due to the bug https://bugzilla.mozilla.org/show_bug.cgi?id=44790.

Bye

Simon
Simon, are we sure of that? Are articles that lose their connection to the en-US article having the language "Unknown"? If that's the case, then these two bugs are definitely related.
David,

I'm quite sure that, when I or one of my peer translators click on "Translate this page" and save the first translation, that page is saved without language id.

So I think that a person unaware of this issue who completes a translation, will not know how to bind it to the correct locale and so the page will remain without locale and unbound to the original - and the natural effect of this is the cluttering of the staging area... 

The people from the Italian support forum have learned how assign the language id after the translation and so this problem is somehow circumscribed (I found only some 5 articles in the whole list posted by Chris, all 5 articles were released from "occasional" translators).

Simon
Simon, I'm not seeing what you're seeing here. If I visit an en-US article with the sv-SE locale in the URL, e.g. http://support-stage.mozilla.org/sv-SE/kb/Common+issues+fixed+in+Firefox+3 and then click Translate this page, Swedish is pre-selected in the list of languages. I also tried to actually edit and save it, and the language is kept.

If I go to http://support-stage.mozilla.org/en-US/kb/Common+issues+fixed+in+Firefox+3 instead (with "en-US" in the URL), something else happens. I then get the first language in the list selected when clicking Translate this page, i.e. Albanian. But again, no "Unknown" language is in the list, or is selected after I save.

I still can't find a reliable way to reproduce it. Any ideas?
Yes, it is the pre-selected language, but this attribute will not be actually set.

But OK. I will make a test with an article not yet translated in Italian.
I will post the results here.

Allright?
Sounds good. I just did the same with a sv-SE article (on staging) but couldn't reproduce the bug.
Attached image Translation Step 1 — 

    
    

    
  

      
      
      
      

        Attached image
          
        Translation Step 2
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached image
          
        Translation Step 3
        — 
      

    


  

    
    

    
  
Hi David,

I uploaded three images. As you can see:

Step 1: clicked on the "Translate this page link" - the proposed language is Italian

Step 2: the Italian title is set, clicked on Save

Step 3: logged out, open SUMO page again, logged in: the article does exist but it has no language id - you can see the "Translate this page" link.


Simon

    
    

    
  
I forgot: the article link is

http://support.mozilla.com/it/kb/Le+barre+degli+strumenti+e+il+contenuto+della+pagina+appaiono+di+dimensioni+eccessive+dopo+l'aggiornamento+a+Fireofx+3

It has no fallback to the original 'cause it is - again - not bound to it.

Simon


P.S. Don't hate me ;-)

    
    

    
  
Is the article also moved to the KB category, or is it still just a staging article? I need to know in order to reproduce this. :)

    
    

    
  
It is in the staging area.

I think all the 270+ articles were in the staging area, aren't they?

    
    

    
  
I can't reproduce this on the staging server. Can you try if the same thing happens on http://support-stage.mozilla.org (user/pass: support/stage)?

    
    

    
  
I tried on the production server. Translated http://support.mozilla.com/en-US/kb/Cannot+use+or+save+passwords+after+upgrading+Firefox into http://support.mozilla.com/sv-SE/kb/Skamtest. The Swedish article seems connected (I can select English again from the Language selector at the bottom). 

Simon, does this error happen every time for you?

    
    

    
  
Yes, it happens every time - but from a certain date ahead (I mean, I think it did not happen in April or so).

I seem to remember that Delphine, the French localizer, experienced this bug too. 

Maybe we can hear her.

    
    

    
  
Hmm.. I don't see why it doesn't happen for me. Could you create a screencast showing the exact steps you take (jingproject.com)? Could you also verify that you get the same problem on the staging server?

    
    

    
  
If it is really not replicable consistently, one possibility might be that it has something to do with db replication delay, or some other kind of delay...

    
    

    
  
Can we think about a connection between this issue and the date the articles were released?

I mean: it happened with an article about the plugin Shockwave who was created in his first version on 07/25/2007.

We mainly focused, in recent times, on this kind of articles. I would like to test it on a more recent page.

If I wrote something stupid, please ignore this message...

    
    

    
  
Again: tried on the atage server with this article:

http://support-stage.mozilla.org/it/kb/Common+issues+fixed+in+Firefox+3

and had the same problem. The translation would be:

http://support-stage.mozilla.org/it/kb/Problemi+comuni+risolti+con+Firefox+3

and again the page is not bound to its original, nor it has a language id.

    
    

    
  
(In reply to comment #22)
> Yes, it happens every time - but from a certain date ahead (I mean, I think it
> did not happen in April or so).

Me, too.
This issue exists since bug 444995 was reported.

    
    

    
  
Would it be possible to film a screencast showing the exact steps you take when this happens? That will help QA dig deeper and find the cause... I can't reproduce it with the Swedish locale. Thanks!

    
    

    
  
I will try.

I don't know how to record a screencast on Linux, but maybe I could on a virtualized Windows machine.

    
    

    
  
I have recorded the screencast of reproducing this issue using Wink.
http://mozilla.l10n.jp/~mar/sumo/SUMO-bug451509.htm

http://support.mozilla.com/ja/kb/Thunderbird+%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6?bl=n

Steps:
1. click "Translate this page" link.
2. type article's title and set locale to 日本語(ja).
3. click "翻訳ページを作成" (create page?).
4. check categories and enter description.
5. click "プレビュー" (preview) button.
6. checked categories are cleared, so check again.  (This seems another bug.)
7. save the article in "Staging Area".
8. the article has saved, but no locale links at the bottom of the page.
9. after that, see the original en-US article. I opend en-US article directly. (http://support.mozilla.com/en-US/kb/Thunderbird)
10. the original article has not linked to ja article.

* "Translate this page" link is still shown on the top of
http://support.mozilla.com/de/kb/Thunderbird

    
    

    
  
(In reply to comment #28)
> Would it be possible to film a screencast showing the exact steps you take when
> this happens? That will help QA dig deeper and find the cause... I can't
> reproduce it with the Swedish locale. Thanks!

David, maybe you could try making a minor edit to it locale and Simon can do the same to the Swedish locale? That would give us some clue as to whether this is happening on specific locales, or specific account types.

    
    

    
  
I can confirm that all the steps performed by Masahiko Imanaka (thanks alot!) are the same as mine.

@ Lucy and David: no problem to make this test. I was just asking you to perform the same operation with an account with the same privileges as mine (not an admin account). Just tell me which article I have to edit.

Ciao

    
    

    
  
IMO, this is more a result of bug 435148 [Remove language selector from article editor (or make it only available to admins)]. In other words, if you create a new article, and you're not an admin, there's no language selector at all.
For example, this item on the list <http://support.mozilla.com/en-US/kb/where+to+see+downloads>, does not have the "Translation in progress" note, and appears to be in English. <http://support.mozilla.com/en-US/kb/Help+with+Firefox+download+window+not+showing+the+download+list> is another one.

    
    

    
  
Sorry, Chris, I'm afraid I don't understand.

I think it is a good thing if no-one can change the language of an already written article, but I do see the language selector upon creating a new translation.

    
  
Target Milestone: 0.7.1 → 0.7.2

    
    

    
  
It appears for you, because you are a locale leader.

I've reproduced this bug in two scenarios:
* English contributor creating a new article: <http://ilias.ca/flashback/nolang.html>.
* Non-English contributor creating a translation: <http://ilias.ca/flashback/nolang2.html>.

    
    

    
  
Great stuff Chris. So, the second screencasts seems to suggest that this happens all the time for normal contributors. Nelson, is this helpful for finding the cause for this? Test with a normal contributor account and it seems to be happening all the time.

    
    

    
  
Run out of time for these.
Target Milestone: 0.7.2 → 0.7.3

    
  
Assignee: laura → paul.craciunoiu

    
    

    
  
(In reply to comment #31)
> sorry, it's "ja" locale.
> http://support.mozilla.com/ja/kb/Thunderbird

I haven't succeeded to create a page that has the same title as an already existing page. I get a "page already exists".
I believe the above link sees the English version of page "Thunderbird", with the "ja" local for the rest of the site. Really not what you'd expect...
Assignee: paul.craciunoiu → laura

    
  
Assignee: laura → paul.craciunoiu

    
    

    
  
I couldn't reproduce the bug, tested with two different locales.

Is there currently a way to find existing articles with unknown language so we can fix them?

    
    

    
  
(In reply to comment #40)
> Is there currently a way to find existing articles with unknown language so we
> can fix them?

<http://support.mozilla.com/tiki-listpages.php?offset=0&sort_mode=lang_asc&maxRecords=278>

It's basically listpages.php, sorted by language. At some point in the list on that page, you'll see articles with a language assigned.

    
    

    
  
(In reply to comment #39)
> I haven't succeeded to create a page that has the same title as an already
> existing page. I get a "page already exists".

Please see this page.

Thunderbird について
http://support.mozilla.com/ja/kb/Thunderbird+%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

    
    

    
  
r20249

This fix allows the original author of the page (translated version or original version) to select the language of the page he is newly creating. I think this is the best and simplest fix, I only changed/added 4 lines of code... although after many other attempts :)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED

    
    

    
  
Oh, yes, I only committed to trunk for now. Please test first, the changes are minor. If that's good then it can go to production. I've tested cilias' mentions as per comment #c36

(In reply to comment #36)
> * English contributor creating a new article:
> <http://ilias.ca/flashback/nolang.html>.
> * Non-English contributor creating a translation:
> <http://ilias.ca/flashback/nolang2.html>.

    
    

    
  
Chris -- if you have time, could you look at this?; otherwise, I'll get to it.  Thanks!

    
    

    
  
Nevermind; much simpler than I thought, once I read what Paul implemented.

Verified FIXED on http://support-stage.mozilla.org/tiki-editpage.php?page=fdsfsfsd&quickedit=Edit&amp;login -- Chris can reopen if it isn't what he wanted.
URL: http://support-stage.mozilla.org/tiki...
Status: RESOLVED → VERIFIED

    
  
Whiteboard: tiki_triage

    
    

    
  
Please test against trunk as a lot of changes have been made
Whiteboard: tiki_triage → tiki_test

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: