Ticket #9089 (closed Bug: wontfix)

Opened 7 years ago

Last modified 4 years ago

Errors when negotiating languages when locales directory is used in Products namespaced packages

Reported by: erral Owned by:
Priority: major Milestone: 3.3.x
Component: Internationalization Version: 4.1
Keywords: PTS Cc: dukebody, libargutxi@…, dimo


(sigh, after 15 minutes writing the bug, I've lost everything because when I hit preview I hadn't writtn the summary :'()

Steps to reproduce:

  • Create a Plone 3.2.2 buildout
  • Add Products.LinguaPlone and Products.RedirectionTool as eggs and zcml lines
  • Execute the buildout
  • Add a Plone site
  • Go to Site Setup -> Additional Products, and install LinguaPlone.
  • Add Basque and Spanish as supported languages, and Basque as default language.
  • Go to the Plone Site and change language to have the interface in Basque (Euskara).
  • Add a Folder (Elementua gehitu -> Karpeta), and inside it some News Items (Albistea). Set Folder's view to be folder_summary_view (Bistarate Unitatea -> Mosaiko ikuspena).
  • You will see dates correctly localized (something like admin-(e)k eginda — 2009/04/02 16:17 ).
  • Go to Site Setup (Atariaren Konfigurazioa) -> Additional Products (Produktu gehigarriak) and install RedirectionTool.
  • Go back to the folder created beforehand. You will see a new tab added by RedirectionTool (Alias) and the dates localized in English (something like admin-(e)k eginda — Apr 02, 2009 04:17 PM ).

Tracking the call stack behind the scenes, I've found that Products.PlacelessTranslationService patches zope.i18n's language negotiator to memoize it (using Products.PlacelessTranslationService.memoize.memoize_second). The first time the negotiator is called is when Plone tries to translate "Alias" into basque. RedirectionTool doesn't have basque translation, so the negotiator decides to return the translation in English, and returns 'en'. So far so good. PTS memoizes this result, and when toLocalizedTime tries to get the translated date (in the plonelocales domain), PTS returns the memoized result and thus the date is shown in English although a basque translation exists for the datetime format used there.

As a temporary solution, I have patched PTS not to memoize the negotiator, and everything works OK in the Plone site.

Products.RedirectionTool uses a locales folder layout to provide its translations, so I have commented the i18n:registerTranslations directive in its configure.zcml file, and moved the PO files to a i18n folder layout. With this configuration, the translations for RedirectionTool are taken correctly and the dates are also shown correctly.

It seems that Plone (or Zope behin the scenes) doesn't handle in the same way the language negotiation thing when using locales folder layout for PO files in Products namespaced packages.

You can contact me for more info, I've spent more than 3 days tracking down this bug.


Change History

comment:1 Changed 7 years ago by erral

  • Cc dukebody added

comment:2 Changed 7 years ago by erral

  • Cc libargutxi@… added; dukebody removed

comment:3 Changed 7 years ago by dukebody

  • Cc dukebody added

comment:4 Changed 7 years ago by erral

This could be related to  http://dev.plone.org/plone/ticket/8968 ? Specially because of thess paragraphs:

zope.i18n does no longer support the i18n folder layout but only the locales folder approach. The locales approach is the one in conformance with the gettext standard. Ending the confusion of two different approaches and their subtle differences in regard to being allowed in packages versus Products, should avoid future confusion.

With the i18n updates included in Plone 3.3 there's no longer any reason why locales folders couldn't be used for all translation files in Plone 3.x, so add-ons can prepare themselves for this move.

The language negotiation handling provided by PloneLanguageTool so far did tie into PlacelessTranslationService and Zope2's Products.Five provided the integration into the actual request handling. PloneLanguageTool will have to be changed to integrate itself directly into the request handling.

comment:5 Changed 6 years ago by dimo

  • Cc dimo added

comment:6 Changed 6 years ago by dimo

I can confirm this bug even in packages in other namespaces. Specifically plumi.locales. The Plumi translations would randomly stop appearing and the only way to restore them was by removing plumi.locales and putting the po files in the instance/i18n dir.

After reading the above and removing the memoize_second call from Products/PlacelessTranslationService/patches.py the plumi.locales translations worked fine.

I'd love to find a more elegant solution other than patching over the PTS patch to prevent it from memoizing the zope.i18n.negotiator and I wonder if there would be a significant performance penalty without the memoize_second wrapper.

comment:7 Changed 5 years ago by vincentfretin

Hi, do you still have the issue with latest Plone 4? If no, I'll close the ticket.

comment:8 Changed 4 years ago by kleist

  • Status changed from new to closed
  • Version set to 4.1
  • Resolution set to wontfix

Plone 3 not supported.

Note: See TracTickets for help on using tickets.