Language "locked in" on first page load about django-tinymce4-lite HOT 10 CLOSED

With model field a widget is instantiated only once on Django app start. This is how Django works. So your solution for your particular scenario seems to be correct.

from django-tinymce4-lite.

@op are you importing the gettext or gettext_lazy function as your _ alias?

from django-tinymce4-lite.

I'm closing this issue because of no follow-up.

from django-tinymce4-lite.

I think the question in my previous message was irrelevant, I mistunderstood the purpose of the screenshot: this is not an issue with _('Description') in the OP’s code (we see it translated to Spanish in the screenshot), but with the language config of tinymce itself.

I now understand the bug report and agree with it. get_language_config calls django’s get_language in TinyMCE.__init__, but it should be done during rendering so that there is a current request with its specific language. (I saw the issue on a page served in French for a site that defaults to English.)

Please reopen!

from django-tinymce4-lite.

The problem is not that the language is looked up at import time!

I use tinymce in the admin only; the form object is created for each request, so TinyMCE.__init__ is called within a request context, and the language code is correct.

The problem is that my language code is fr and language files available with TinyMCE are fr_FR.js and fr_CH.js. (For the record the differences between these two aren’t really country-specific terms, but different choices, mistakes and missing strings.)

I don’t want to change my language code; fr_FR would be incorrect as the audience is in Québec, and I don’t want fr-CA in URLs either. From django viewpoint, it is correct to define the available languages as fr and en.

A proper fix should probably be in TinyMCE itself. But for a quick fix, I’ve tried a small change in django-tinymce4-lite: change get_language_config to fallback to "code_CODE" if language_file_exists(code) is false.

This logic allows various configs to work:

• source fr-fr → convert fr_FR → found file fr_FR.js
• source fr-be → convert fr_BE → no file fr_BE.js → no file fr.js → found file fr_FR.js
• source fr → convert fr → no file fr.js → found file fr_FR.js

from django-tinymce4-lite.

@romanvm This is an issue for all sites that don’t use lang+country codes.
Can you reopen and discuss my proposed fix?

from django-tinymce4-lite.

@merwok

This is an issue for all sites that don’t use lang+country codes.

This is not true. E.g., a site with uk country code works perfectly fine. I agree that this may be an issue when Django language code does not match the name of the corresponding TinyMCE translation file. The case of Django's 4-letter code -> TinyMCE's 2-letter code is easy one and it was addressed. But the reverse case is not that obvious because of so many possible 4-letter language codes. I understand that you may prefer fr_FR as the default, but you are not the only user and French is not the only language with country variations, and I don't see the point of addressing specific per-user cases in a generic package. For your case a workaround is pretty simple: just rename TinyMCE's translation file from fr_FR.js to fr.js.

from django-tinymce4-lite.

This is not true. E.g., a site with uk country code works perfectly fine.

Right, I misqualified my statement!

I understand that you may prefer fr_FR as the default, but you are not the only user

Well I don’t (my project using tinymce is for an audience in Québec, Canada) but choosing code_CODE when code.js does not exists seemed reasonable.

For your case a workaround is pretty simple: just rename TinyMCE's translation file from fr_FR.js to fr.js.

Well I don’t control the TinyMCE files which are part of django-tinymce’s static files. If there was no other choice I could copy fr_FR.js to fr.js during deployment.

Thanks for the changes in 0bf1a65, I’ll use that to add custom language settings directly in default profile or mce_attrs.

from django-tinymce4-lite.

but choosing code_CODE when code.js does not exists seemed reasonable.

I disagree. In a case when for some language multiple country-specific variants are available, like for French or German or even English, who will decide which country-specific variant should be considered as the "master" one? Personally, I don't know, and, I'm afraid, in some cases this choice may even be politically colored. So I don't want to make that choice.

from django-tinymce4-lite.

This should be fixed in v. 1.7.5. I'm closing this issue.

from django-tinymce4-lite.