RTL languages broken in 4.6 dev branch?

philwareham · 2014-02-23 12:51:56

I’ve just tried to switch to a RTL language (Farsi, Algerian Arabic, etc) and I’m getting a fatal error:

Fatal error: Uncaught exception 'Exception' with message 'invalid_argument: locale' in /Users/philwareham/Sites/svn/Textpattern SVN Playground/textpattern/vendors/Textpattern/L10n/Locale.php:145 Stack trace: #0 /Users/philwareham/Sites/svn/Textpattern SVN Playground/textpattern/include/txp_lang.php(323): Textpattern_L10n_Locale->setLocale(0, 'ar-dz') #1 /Users/philwareham/Sites/svn/Textpattern SVN Playground/textpattern/include/txp_lang.php(52): save_language() #2 /Users/philwareham/Sites/svn/Textpattern SVN Playground/textpattern/index.php(231): include('/Users/philware...') #3 {main} thrown in /Users/philwareham/Sites/svn/Textpattern SVN Playground/textpattern/vendors/Textpattern/L10n/Locale.php on line 145

Can anyone else confirm please?

Gocom · 2014-02-23 14:49:50

Not to do with RTL languages, and its not really a broken either. Your operating system just doesn’t have locale for those languages installed. We may want to capture the exception on txp_lang.php, and let the language change the place, or prevent choosing the language the OS can not support.

If you choose a language your OS doesn’t support, currencies, dates and numbers (decimal pointers etc) will be displayed wrong (in wrong language and formatting).

philwareham · 2014-02-23 21:35:08

Ok Jukka, thanks for the explanation. Pretty sure I had this working on OSX 10.8, but now running 10.9. I’ll look into it further.

phiw13 · 2014-02-24 00:33:28

Jukka, I think there is something else at play. There are (at least) 3 languages that trigger that error: Arabic, Urdu and Persian. All other languages I tested load fine. The 3 languages mentioned are supported by the OS – the OS has the necessary resources, fonts, etc. They are not ‘active’ in the System Prefs. > International pane, but other languages I tested are not ‘active’ either (e.g. Russian, German, Hebrew, Korean).

Testing further, I enabled (activated) Persian is the System Prefs, restarted the computer, but the error persist.

10.9.1, stock Apache and PHP. As Phil mentioned, this worked fine under OS X 10.8 and older. I’m not sure, but I seem to remember testing Persian a couple of months back – after I upgraded to 10.9 – and it didn’t trigger that error.

Gocom · 2014-02-24 10:42:50

What Textpattern uses are locales, which are interacted through PHP’s C wrapper that then calls C’s setlocale. Its separate from your GUI and its language options.

What does running the following command (in Terminal) print out?

$ locale -a

Running that will list all locale files you have installed. To be able have full Arabic experience, the list must contain ar_DZ.UTF-8. Locale files themselves are part of the system, so OS upgrades (and even patches) will likely reset them. To support other languages, you will have to generate new locale files for that language. Mac OS comes with localedef utility:

$ man localedef

Locale files themselves are hosted in /usr/share/locale directory and should be saved there. If the utility is still broken (it used to be), you can copy+paste an existing locale (directory) and manually modify its files to contain proper information (e.g. currency symbols and so on).

But, as I said already, we should capture the exception and either prevent the language selection or let the language change happen even if there isn’t proper locale for it. The txp_lang.php file is just missing a try-catch statement. There is nothing wrong in the code itself. The new code is just error-aware.

philwareham · 2014-02-24 11:09:57

This is what I get on a clean install of OSX 10.9, looks like the languages such as fa-ir are not supported out-of-the-box, as Jukka has said:

af_ZA
af_ZA.ISO8859-1
af_ZA.ISO8859-15
af_ZA.UTF-8
am_ET
am_ET.UTF-8
be_BY
be_BY.CP1131
be_BY.CP1251
be_BY.ISO8859-5
be_BY.UTF-8
bg_BG
bg_BG.CP1251
bg_BG.UTF-8
ca_ES
ca_ES.ISO8859-1
ca_ES.ISO8859-15
ca_ES.UTF-8
cs_CZ
cs_CZ.ISO8859-2
cs_CZ.UTF-8
da_DK
da_DK.ISO8859-1
da_DK.ISO8859-15
da_DK.UTF-8
de_AT
de_AT.ISO8859-1
de_AT.ISO8859-15
de_AT.UTF-8
de_CH
de_CH.ISO8859-1
de_CH.ISO8859-15
de_CH.UTF-8
de_DE
de_DE.ISO8859-1
de_DE.ISO8859-15
de_DE.UTF-8
el_GR
el_GR.ISO8859-7
el_GR.UTF-8
en_AU
en_AU.ISO8859-1
en_AU.ISO8859-15
en_AU.US-ASCII
en_AU.UTF-8
en_CA
en_CA.ISO8859-1
en_CA.ISO8859-15
en_CA.US-ASCII
en_CA.UTF-8
en_GB
en_GB.ISO8859-1
en_GB.ISO8859-15
en_GB.US-ASCII
en_GB.UTF-8
en_IE
en_IE.UTF-8
en_NZ
en_NZ.ISO8859-1
en_NZ.ISO8859-15
en_NZ.US-ASCII
en_NZ.UTF-8
en_US
en_US.ISO8859-1
en_US.ISO8859-15
en_US.US-ASCII
en_US.UTF-8
es_ES
es_ES.ISO8859-1
es_ES.ISO8859-15
es_ES.UTF-8
et_EE
et_EE.ISO8859-15
et_EE.UTF-8
eu_ES
eu_ES.ISO8859-1
eu_ES.ISO8859-15
eu_ES.UTF-8
fi_FI
fi_FI.ISO8859-1
fi_FI.ISO8859-15
fi_FI.UTF-8
fr_BE
fr_BE.ISO8859-1
fr_BE.ISO8859-15
fr_BE.UTF-8
fr_CA
fr_CA.ISO8859-1
fr_CA.ISO8859-15
fr_CA.UTF-8
fr_CH
fr_CH.ISO8859-1
fr_CH.ISO8859-15
fr_CH.UTF-8
fr_FR
fr_FR.ISO8859-1
fr_FR.ISO8859-15
fr_FR.UTF-8
he_IL
he_IL.UTF-8
hi_IN.ISCII-DEV
hr_HR
hr_HR.ISO8859-2
hr_HR.UTF-8
hu_HU
hu_HU.ISO8859-2
hu_HU.UTF-8
hy_AM
hy_AM.ARMSCII-8
hy_AM.UTF-8
is_IS
is_IS.ISO8859-1
is_IS.ISO8859-15
is_IS.UTF-8
it_CH
it_CH.ISO8859-1
it_CH.ISO8859-15
it_CH.UTF-8
it_IT
it_IT.ISO8859-1
it_IT.ISO8859-15
it_IT.UTF-8
ja_JP
ja_JP.eucJP
ja_JP.SJIS
ja_JP.UTF-8
kk_KZ
kk_KZ.PT154
kk_KZ.UTF-8
ko_KR
ko_KR.CP949
ko_KR.eucKR
ko_KR.UTF-8
lt_LT
lt_LT.ISO8859-13
lt_LT.ISO8859-4
lt_LT.UTF-8
nl_BE
nl_BE.ISO8859-1
nl_BE.ISO8859-15
nl_BE.UTF-8
nl_NL
nl_NL.ISO8859-1
nl_NL.ISO8859-15
nl_NL.UTF-8
no_NO
no_NO.ISO8859-1
no_NO.ISO8859-15
no_NO.UTF-8
pl_PL
pl_PL.ISO8859-2
pl_PL.UTF-8
pt_BR
pt_BR.ISO8859-1
pt_BR.UTF-8
pt_PT
pt_PT.ISO8859-1
pt_PT.ISO8859-15
pt_PT.UTF-8
ro_RO
ro_RO.ISO8859-2
ro_RO.UTF-8
ru_RU
ru_RU.CP1251
ru_RU.CP866
ru_RU.ISO8859-5
ru_RU.KOI8-R
ru_RU.UTF-8
sk_SK
sk_SK.ISO8859-2
sk_SK.UTF-8
sl_SI
sl_SI.ISO8859-2
sl_SI.UTF-8
sr_YU
sr_YU.ISO8859-2
sr_YU.ISO8859-5
sr_YU.UTF-8
sv_SE
sv_SE.ISO8859-1
sv_SE.ISO8859-15
sv_SE.UTF-8
tr_TR
tr_TR.ISO8859-9
tr_TR.UTF-8
uk_UA
uk_UA.ISO8859-5
uk_UA.KOI8-U
uk_UA.UTF-8
zh_CN
zh_CN.eucCN
zh_CN.GB18030
zh_CN.GB2312
zh_CN.GBK
zh_CN.UTF-8
zh_HK
zh_HK.Big5HKSCS
zh_HK.UTF-8
zh_TW
zh_TW.Big5
zh_TW.UTF-8
C
POSIX

I’ll try to manually create these later and let you know how I get on.

phiw13 · 2014-02-24 12:37:35

Gocom wrote #279190:

What Textpattern uses are locales, which are interacted through PHP’s C wrapper that then calls C’s setlocale. Its separate from your GUI and its language options.

Ah, thanks for the explanation. As can be seen from Phil’s list, Arabic, Farsi and Urdu are indeed missing. They were never available on OS X afaict (checked 10.4, 10.6)

philwareham wrote #279191:

I’ll try to manually create these later and let you know how I get on.

Thanks for playing with those. I’l see if I have time this week to investigate on my side…

philwareham · 2014-02-24 13:02:04

The Textpack codebase has changed fairly recently I think, which maybe why this locales stuff has cropped up now. Fairly certain I had Farsi running on a test site a few months back when I was working on RTL improvements.

Anyway, I’ll look into this soon as I get some spare time.

Gocom · 2014-02-27 14:03:38

Still, there is nothing to investigate. Just:

we should capture the exception and either prevent the language selection or let the language change happen even if there isn’t proper locale for it. The txp_lang.php file is just missing a try-catch statement.

Its not an error, just uncaught expected exception.

ax · 2015-07-03 06:47:16

You will encounter this error message even with common languages like English (United States) under Debian, if you did not select it during minimal install.

Gocom wrote #279310:

Its not an error, just uncaught expected exception.

Therefore, I think that it would be better to catch this uncaught expected, if I may say so.

superfly · 2016-09-27 14:21:45

Heads up for anyone else who has Problems updating from TXP 4.5.7 to TXP 4.6.0. I had the following Error:

Fatal error: Uncaught exception 'Exception' with message 'invalid_argument: locale' in PATH_TO/textpattern/vendors/Textpattern/L10n/Locale.php on line 141

I had two <txp:posted> Tags with the Attribute value for lang="de". After changing the value to lang="de_DE" the Error went away. This Error also occurred with other languages.

Bloke · 2016-09-28 09:54:08

superfly wrote #301786:

invalid_argument: locale

Thanks for the heads-up. This should be fixed in Txp 4.6.1. There may be other places we should catch this error, but we’ll take these on a case by case basis. See Issue 603 for more.

Textpattern CMS

Textpattern CMS support forum

#1 2014-02-23 12:51:56