Closed Bug 620095 Opened 15 years ago Closed 11 years ago

Some redirects already localized in some locales still show up in localization dashboard

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: scoobidiver, Unassigned)

Details

Those redirects may have existing localizations, which would prevent us from making them non-localizable. Unfortunately it's difficult to filter by "articles whose parent is X." We should find a way to make that search easier.
> Those redirects may have existing localizations, which would prevent us from > making them non-localizable. https://support.mozilla.com/en-US/kb/Get%20help%20with%20Firefox%204%20Beta had a French localization https://support.mozilla.com/fr/kb/Obtenir%20de%20l%E2%80%99aide%20sur%20Firefox%C2%A04%C2%A0b%C3%AAta and it shows as untranslated in French because the parent-child link has been cut. So it could be non-localizable.
(In reply to comment #2) > and it shows as untranslated in French because the parent-child link has been > cut. So it could be non-localizable. It can only be cut if it has no children at all. Are you sure it doesn't have a translation in another locale?
> Are you sure it doesn't have a translation in another locale? The link has been cut during the migration. May be there have been new translations after. Is it possible to cut child/parent links for English redirects and delete newly orphaned localized articles, so that these redirects don't show up in localization dashboard and don't bias translation count?
(In reply to comment #4) > Is it possible to cut child/parent links for English redirects and delete newly > orphaned localized articles, so that these redirects don't show up in > localization dashboard and don't bias translation count? It's not possible to sever all the links from the English article, which is why I said in comment 1 that we need to make it easier to find localizations of an article.
Can you use the same mechanism as bug 629493 for the search result filtering of redirects?
(In reply to comment #6) > Can you use the same mechanism as bug 629493 for the search result filtering of > redirects? Possibly, but it isn't the correct solution. The articles linked in comment 0 have existing localizations. To be made non-localizable, those localizations need to be cut from the parents or deleted. Then the articles can be made non-localizable and they'll disappear from the L10n dashboards. For Smart Location Bar: +------+--------+------------------------------------------+ | id | locale | title | +------+--------+------------------------------------------+ | 3294 | de | Intelligente Adressleiste | | 3309 | nl | Slimme locatiebalk | | 3341 | uk | Вражаюча панель адрес | +------+--------+------------------------------------------+ For Options Window - Main panel: +------+--------+-------------------------------------+ | id | locale | title | +------+--------+-------------------------------------+ | 2905 | cs | Nastavení Firefoxu - sekce Hlavní | | 2875 | hu | Beállítások ablak - Főlap | +------+--------+-------------------------------------+ For Get Help with Firefox 4 Beta: +------+--------+-------------------------------------------------------+ | id | locale | title | +------+--------+-------------------------------------------------------+ | 5532 | ak | Wie Sie Hilfe zur Beta-Version von Firefox 4 bekommen | | 5430 | uk | Допомога по Firefox 4 бета | +------+--------+-------------------------------------------------------+
The article in comment 8 is related to bug 640805 because it is unlocalizable (Allow translation is unchecked).
Summary: Some redirects still show up in localization dashboard → Some redirects already localized in some locales still show up in localization dashboard
All the articles mentioned in comment #7 seem to have been removed by now. I couldn't find any of them by id, so closing this.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.