topic Re: Edit properties form not showing up in Alfresco Archive

Edit properties form not showing up

grk — Fri, 02 May 2014 13:41:20 GMT

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

Re: Edit properties form not showing up

mitpatoliya — Sun, 04 May 2014 08:58:38 GMT

Any error on User Interface?Any error in log files?
Please add those details.

Re: Edit properties form not showing up

grk — Sun, 04 May 2014 13:17:17 GMT

No message error is provided in the User Interface.
On the logging files, nothing as well, by default. Should I set any particular log4j property to debug, in order to get any possible error? e.g. Javascript errors?

Thank you.

Re: Edit properties form not showing up

kaynezhang — Mon, 05 May 2014 03:58:36 GMT

I guess there might be some illegal character (for example quote without escape) in your Greek language pack which cause a trouble to client side javascript code. So when you click on the "edit properties" button,the javascript code dose not work.

So setting log4j property to debug might not do any help.
You can try to move the following greek i18n properties file to the place


Share/js/alfresco/services/i18n/ActionService_GR.properties
share/WEB-INF/classes/alfresco/site-webscripts/org/alfresco/components/documentlibrary/documentlist-v2.get.properties
share/WEB-INF/classes/alfresco/site-webscripts/org/alfresco/components/documentlibrary/documentlist.get.properties
‍‍‍‍‍

and see what happens in share document library.

Re: Edit properties form not showing up

grk — Mon, 05 May 2014 08:18:17 GMT

First of all, thank you for your help.

Something important before we continue our conversation: I noticed that on IE, the form is displaying normally in greek (probably the only time that a developer is happy with IE). What does this mean? The files can't be corrupted or with missing strings, because IE loads them!

I didn't use an .amp file for the language pack, rather than just upload a .jar file. So, the file you said ActionService_el.properties is not on the alfresco repository. I unjared the .jar file in my desktop, and copied the file as documentlist.get_el.properties (and -v2 likewise). Nothing happened. Then I created a backup of my documentlist.get.properties and replaced it with the greek version. Nothing in particular, regular english form showing up.

Re: Edit properties form not showing up

grk — Mon, 05 May 2014 11:36:13 GMT

I opened up a debugger to see what's going on upon the loading of any Alfresco page, and more specifically in a document library. So, first of all, I get the following error:

<b>TypeError: b is null</b>

The javascript is minified, so I do not know in which line this happens, but it happens right after the tags are retrieved, and in a file called "yui-commonXXXXXXXX.js" (XXXXX is a random sequence of numbers and letters).

Next, when I actually click on "edit properties", I can see the GET response, and everything is retrieved normally! I can actually see the HTML that is returned to the browser.. But the thing is that is in the top of HTML tags, and it is hidden..

I suppose a function is not called correctly. Possibly the one with the null pointer?

Re: Edit properties form not showing up

kaynezhang — Wed, 07 May 2014 15:14:03 GMT

You can turn on debug mode by setting the client-debug flag to true in classpath:alfresco\share-config.xml(or extension classpath share-config-custom.xml),share will use the original uncompressed javascript file,or you can just copy the yui-common.js into yui-common-min.js.
And then open up a debugger to see what's going on.It will give you detail null inforamtion

Re: Edit properties form not showing up

grk — Mon, 12 May 2014 11:17:24 GMT

Can you tell me what to type exactly, so as to get non-minified JS?
I tried the following:

First, I wrote on my share-config-custom.xml the following:


  <config>
    <flags>
       <client-debug>true</client-debug>
    </flags>
  </config>
‍‍‍‍‍‍‍

Nothing happened.. Then, I wrote "replace=true" on my config tag, and share didn't even load up. It said that something on alfresco-common.ftl was missing (config.global.flags.childrenMap[key] to be exact)..

Then, I went low-level and edited share-config.xml on the webapps/share.. repository. Now Javascript debugging seems to be enabled, and some of the .js is unminified. But the problem is on a script called "yahoo-dom-event_XXXXXX.js" which is provided minified, still!

It seems that a certain Y variable is not defined in the greek language pack.. Opening up my debugger, and seeing the "
DOM" tab, that Y variable is there, but which property should I see (it has some properties like BUILD, Bubbling, util, lang, etc.)? Is there any information I can provide you with, that could help?

Also, the Alfresco log4javascript shows some information, but no errors or warnings there..

Any help is greatly appreciated guys..

Re: Edit properties form not showing up

mokus16 — Tue, 10 Jun 2014 08:14:02 GMT

We are having the same issue with Slovak language pack - exactly same behavior as grk described. In IE it works and we also identified the same JS, but I don't know how to correct it.

Has anybody found a solution/workaround for this issue?

Thanks in advance.

Re: Edit properties form not showing up

grk — Tue, 10 Jun 2014 09:21:15 GMT

Just confirming that we haven't found any workaround as well.
Obviously a configuration file is missing, but I can't figure out which one. The safest way would be to take a working language pack and rebuild it with our strings, but that would take a while (a long actually..).

Does it have to do that it is loaded up as a .jar file?

Re: Edit properties form not showing up

mokus16 — Thu, 12 Jun 2014 10:42:22 GMT

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.

Re: Edit properties form not showing up

grk — Wed, 02 Jul 2014 12:59:10 GMT

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..

Thank you everyone for your support and help.

Re: Edit properties form not showing up

davidcognite — Thu, 03 Jul 2014 11:09:30 GMT

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.