cancel
Showing results for 
Search instead for 
Did you mean: 

Edit properties form not showing up

grk
Champ in-the-making
Champ in-the-making
I have installed a community language pack for Greek. Everything seems to be working great.

I have some problems though, in some forms. For example, when I press the "edit properties" icon, on a document (when on a folder, not viewing the document), the edit form does not show up.

Does anyone have any idea on how this can be solved?
It is of custom content type, so lack of translations might be one thing. Even so, this happens in all content types, even on the core ones..

12 REPLIES 12

mokus16
Champ in-the-making
Champ in-the-making
We found the error in our case.
Our approach was like this: We extracted our language jar for share, and group by group we were adding directly these property files to the concrete share directories where they belong. This way we identified the group (later the concrete property file) which was causing the error. Then we compared this file with the original EN file and we found out, that in our translation there was an extra placeholder "{0}" in the translation. We removed it, and everything works fine.
Of course I cannot tell you if you are having a similar or same error - this is just a suggestion, which could help and that during translation you have to pay attention to the placeholders as they can cause issues like this.
We are using crowdin and a similar translation was done before for a different field, so we used the suggested text provided by the translator with the extra parameter which we did not notice.

grk
Champ in-the-making
Champ in-the-making
Same here. It seems that in particular, the file "html-upload.get_el.properties" is causing the problem. I removed it and everything seems to be ok now.

Although, after 2 hours of try-and-fail (thank God, share is in a separate tomcat port! Life is too short for alfresco restarts) I can't seem to be able to find the problem with its syntax, based on the respective .get_en file.

Generally speaking, it would be useful to have a syntax-check script for our translations. Is this likely to be caused by a {0} (or any other number) placeholder, in a string that doesn't have any "variables"? Is it something out of bounds (a string having only 1 property and a translation tries to access e.g. {1})? Or should it be plain syntax (e.g. it is spelled {{0} and I am too blind to see). I hope that I will figure it out.. Smiley Very Happy

Thank you everyone for your support and help.

davidcognite
Star Contributor
Star Contributor
Hello,

There are some localisation tools here: https://github.com/davidcognite/alfresco-localisation-tools - these are based on what we use internally to check what comes back from translators so would probably help.

The best way to find issues is to do a side by side comparison with the English file. Check the file format as well - we've had problems with incorrectly encoded files (e.g. a UTF8 BOM in an otherwise ASCII file) breaking things in hard to spot ways; there should only be standard ASCII characters in the file & all extra characters should be unicode escape sequences.

HTH,
David.