This is not common. This error log you are looking at might not be the one that’s actually being used. I see in your php settings that error_log is ‘php_errorlog’, with no path. What is the path of the error log file that you got this message?
Also, try enabling the debug settings in config.inc.php if you can’t access your current php error log file.
Cheers,
Bruno
the path is in root of ojs installation and that it is called php_errorlog
Thanks
I turned on Debug message if something goes wrong in file as you mentioned and I deleted now succesfully keys. I do not see any debug message. Can I find it somewhere?
Thanks
There is only one key that cannot be deleted after several attempts.
The key “section.default.policy” is no longer used and can be removed from “locale/hr_HR/locale.xml”.
Delete this key
Hi @vvucic,
I still think the most likely cause of this is file permissions; compare the file permissions on that file against the permissions on another file where the locale key was successfully removed.
Regards,
Alec Smecher
Public Knowledge Project Team
All permissions are 0644.
It is strange that after turning on debug option for debug if something goes wrong in
config.inc.php
I see that the same file was modified today so the permissions should not be issue. Otherwise it could not be modified. I do not have clue for now, what may prevent deletion of that key.
I deleted that key manually. I am done for that issue. I will open new thread for other issue.
Thanks
Hi @vvucic,
As Bruno noted above, 644 typically isn’t enough, depending on the file ownership and your server configuration. But if you’ve already managed to modify the files via the translator plugin, we’ll assume that’s working.
The translator plugin uses regular expressions to edit the locale files, so the other possibility is that the regular expressions aren’t matching what they expect to in that file. Have you tried linting the XML file with a tool like xmllint? (The function responsible for removing locale keys, including the regular expressions that do it, are here: pkp-lib/EditableLocaleFile.inc.php at ojs-stable-2_4_6 · pkp/pkp-lib · GitHub)
Regards,
Alec Smecher
Public Knowledge Project Team
Hello,
It is possible that the translation I am working on was abandoned before and that in the meantime many things have been changed which cause mismatch. Or, someone changed something in the file so that as you said regular expressions do not match what they expect in that file.
I did not try linting the XML file. Thanks on suggestion.
Should I mark this thread as resolved?
Hi @vvucic,
No need to mark anything resolved – if you run into further problems on the same issue, feel free to follow up here.
Regards,
Alec Smecher
Public Knowledge Project Team
I deleted extra key “section.default.policy” from “locale/hr_HR/default.xml”. I am prompted after deletion to enter translation in Missing keys. Please advise how to fix this.
Thanks
Hi @vvucic,
This key was probably in the wrong locale file.
Regards,
Alec Smecher
Public Knowledge Project Team
What I have to do to fix that?
Thanks
Hi @vvucic,
When you remove the key, it should delete it from the wrong file; then when you’re asked to re-translate it, it should add the key to the correct file. If that’s not what you’re seeing, let me know what’s happening and I’ll see about debugging further.
Regards,
Alec Smecher
Public Knowledge Project Team
I do have the same situation in Serbian translation. After completing Croatian translation I moved to Serbian. I have had the same situation . I got that there is only one extra key which could not be deleted by checking checking box on its left side:
The key “section.default.policy” is no longer used and can be removed from “locale/sr_SR/locale.xml”.
Delete this key
If I would delete it manually I expect the same issue later. Please advise how to delete that key and make sure that late ron in translation I will not have blank filed related to the section default policy.
Thanks
Hi @vvucic,
You’re being warned that section.default.policy should not be in locale/sr_SR/locale.xml because that key should be in locale/sr_SR/default.xml instead. If you’re not able to delete it using the translation tool, as above, ensure that your file permissions permit modification to that file by PHP. If you still can’t delete the key, it’s probably because the regular expression used to match keys for deletion isn’t matching that key for some reason; either compare the key in the locale file against the regular expression (linked above) to find out why, or make the correction manually.
Regards,
Alec Smecher
Public Knowledge Project Team
Hello,
I deleted manually that key from /locale/sr_SR/locale.xml and moved it to /locale/sr_SR/default.xml.
I noticed that it did not have closing tag .
I added it and entered translation. However, in GUI in translator plugin problem remains the same. I can live with it, but I guess it should be fixed in the next release. I will check does translation of that key appear in translated pages and let you know.
Thanks
I’ve replicated this issue in my own install. When operating on locale/sr_SR/default.xml with the “section.default.policy” key, the preg_match() fails for a reason I have not identified.
However, @vvucic, note that the entry in the distributed file ojs/default.xml at ojs-dev-2_4 · pkp/ojs · GitHub does have the closing message tag. In my experience, “missing” the end tag is often a matter of using an editor or terminal that is not Unicode aware. (It really is there, but the display is mangled.) Double check your editor and terminal and confirm against the GitHub source if end tags are “missing”.
Hello, Missing closing tag was in local installation that is installed from installation script on the server of hosting company. I use Geany in GNU/Linux and it does have necessary support.
I will check git clone of your repository too.
Thanks
After I entered closing tag I noticed that newly entered translations were not being saved after clicking on Save button. I removed closing tag that I entered and I see now much less untranslated keys than before. Please let me know if I can assist in solving that strange behavior.
Thanks
Hi @vvucic,
Are you working with an XML validator? After making changes to the file manually, run it through a validator (like xmllint or similar) to make sure no typos are preventing the file from being parsed.
Otherwise, would you be able to put the partial translation up on github? It’s hard to guess what’s happening without being able to look at the files.
Regards,
Alec Smecher
Public Knowledge Project Team