-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Locale-specific string functions should not be used to build classnames #93
Comments
Hi @asmecher! Unfortunately is very hard to test this issue, since I cannot just change my system locale... |
Thanks, @seboettg! Yes, this is a nasty one and pops up all over the place (see also https://bugs.php.net/bug.php?id=18556). I feel sorry for Turkish developers who run into this stuff while trying to learn! I tried to run the tests, but I'm getting a lot of test failures (on the
Maybe this is fixed elsewhere? (PHPUnit 8.5.2, PHP 7.4.3.) I suspect you can get the testing to run under the Turkish locale by following these steps (Linux):
I suspect you could add a new test that incorporates the |
Thank you @asmecher
But I think the unit tests might work when you run
|
Thanks, that got it. The PHPUnit test output from issue-93 with |
Ah, ok! You must run |
Gotcha, but the log file linked above still shows some locale-specific assumptions that Turkish breaks. See e.g.
|
…on with systems that use tr_TR locale
In |
Very close!
|
…on with systems that use tr_TR locale
Okay... once again, please! 👍 |
Down to 1!
|
Oh no! I'm so sorry to have to bother you with these tests. |
…on with systems that use tr_TR locale
…on with systems that use tr_TR locale
Ok, I have now set up my raspi so that I can do these tests by myself. I figured out, that there seems to be a problem with case insensitive regular expressions...
For example this pattern does not work with Turkish locale. |
…on with systems that use tr_TR locale / cleanup
I guess all issues are solved now. @asmecher can you confirm that? |
Tests pass!
|
Ok, version 2.2.2 is released and contains these fixes. I will close this ticket. If you think additional doings are necessary, feel free to reopen this bug report. |
Thanks for your excellent work as always, @seboettg! |
Please follow the general troubleshooting steps first:
Bug reports:
Factory.inc.php
usesucfirst
to assemble a constraint class name for inclusion. However, it uses theucfirst
function to do so, and upper/lower case behaviour in the current locale may not match the code's expectations.For example, when using the
tr_TR
locale,ucfirst('i')
yields"i"
, leading to:(This is a common Turkish locale gotcha; see e.g. smarty-php/smarty#155 and the proposed fix at smarty-php/smarty#586. I have not checked elsewhere to see if other locale-sensitive functions are used in this way in this library.)
Originally reported by an OJS end user: https://forum.pkp.sfu.ca/t/articles-in-the-second-locale-language-do-not-show/62967
Used CSL stylesheet:
(Any)
Used CSL metadata
(Any)
The text was updated successfully, but these errors were encountered: