I had tried the v1.0 and reported the IE bug to the author, and he worked out a solution so quickly. Impressive!
Thanks to the author! (and hope Google will fix that bug soon)
I think this plugin is a great idea. Thanks to the author.
The original intention of this plugin was to eliminate the need to edit the source of a GPL extension every time you updated it.
However, our understanding of the GPL is that any extension that isn't also GPL is a violation of the core Joomla license. That's why you don't see non-GPL extensions in the JED.
In the same way, you can't say "this is GPL with these extra restrictions", which many extensions try to do. It's simple: if there are extra terms and conditions, then it's not a GPL license. GPL v3 makes this much more explicit.
However, if you purchase a non-GPL extension, you entered into an agreement with the developer and accepted their license. If you choose to use this plugin to violate that license, it is entirely your responsibility. Our position is that non-GPL extensions should never be installed in the first place.
However, I noticed that there are very limited date format options in the settings. And no one matches our Chinese people's tradition. For example, we want a date format as: %Y 年 %b 月 %d 日。I tried to define such a format in the language file but failed.
Hope the author will add full customization option to date format in next release. Thanks.
Can you raise this point (with a little more detail) in the Jevents 1.5 forum and we'll see what can be done.
Please use .ini format language file so I can make full translation for this component. Thanks.
At first thank you for review and rate!
You shouldn't edit .php language file .
To add new translation you should go to the BE -> Comopnents -> BearLeague -> Languages -> 'New' button and translate all the words. Then press 'Save' button and make your translation default
This component lacks another feature: uploader. FTP transfer is not convenient for each user, so an uploader is good.
If turn off the captcha at frontend, it works very good. When CAPTHCA on, it kept saying that the security code is not correct, but I WAS sure I had entered the correct code.
Another bug is, I am using Simplified Chinese language at frontend. Then the corresponding CAPTCHA word file should be cn.txt, NOT zh.txt. However, this component ONLY accept zh.txt.
If such a complicated CAPTHCA system is not easy to iron out, just use something simpler.
Thanks to the author.
Thank you for your feed-back.
I'm guessing you were using version 2.0.0 because this problem with CAPTCHA was long discussed on our forum and it appeared only on some browsers and in some cases. That is way I didn't noticed it before the release of that version.
It was fixed in 2.0.1.
About the problem with the words files for CAPTCHA, I don't think it's a bug, ( the first 2 letter of the language code are used ), but this is not the place to discuss it.
Maybe I'll add this as a parameter of the extension.
I find it strange ( even a little offensive ) that instead of asking for help on our forum or by email you suggest using a simpler CAPTCHA system. Maybe you can point me to another system that offers the possibility to easily add words in different languages and set the font and background colors for this kind of system.
When I check the language files, I noticed that the author used php format for language files, NOT ini format, which should be respected as the J1.5 standard. This is the first fault.
The second fault is, there are two duplicate language files respectively in folder languages and Language_Module. I made a Chinese language translation and uploaded it to the languages folder, but it can't be detected. This component can ONLY detect the language file in Language_Module folder. So, why you created the languages folder?
The third fault is, even after I put my translation language file into Language_Module folder, it can't pick up my translation automatically. I had to choose the language manually at backend settings page of this component. You know, J1.5 has parameter to allow extensions pick up correct php format language files, why didn't you use it?
The fourth and the largest fault is, I can't find the advantage of this component. Imagine this: I create a new section in the Joomla com_content and title it as Reviews, then I can create Categories inside this section. Next, I can write reviews just like new article(content). And the visitors can rating and comment my article(review) via my commenting component. You know, there are many commenting component which can also offer the rating stars feature.
So, what is the advantage of installing a new component to write reviews?
You are reviewing an alpha version i.e. very early build for Joomla 1.5. As you noticed the language is currently incomplete and in two parts which makes it far from ideal. In it's current state it is only there as a place holder while the component is being fully converted from Joomla 1.0 -> Joomla 1.5. The ini format will most likely not be used while compatibility is maintained with 1.0. Myself and others find the component useful, if you don't then that is fine.
In addition, it can work with CB Capthca plugin to provide security.
However, I hope this plugin can allow user/visitor to send file attachments along with the text message. Of course there should be new parameter to limit the file size and file type.
BTW, I noticed that all those backend parameters of this plugin was not included in the language file. I want to make a complete Chinese translation but can't. There is also one line of English words above the frontend mail form which was not in the language file, it is "If you want to contact this person, you may use this email-form".
Please make a complete language file and then I can make a complete translation.
Thanks to the author.
However, the language file is not complete yet so that I can't make a full translation for it.
Hope the author will add those lost strings into the language files.
Although I speak a number of languages, by far my knowledge of all the kindly submitted translations is insufficient. In case a translation string is unavailable in a certain language file, the original variable will show up. The same variable should be in the language file with its translation. If not, you would know your own language better than I do to translate it.
Another problem is, this plugin will also try to generate thumbnails for my math equation images which were output by mimiTeX plugin and made those images can't be displayed.
I also tested another famous plugin MultiThumb, MultiThumb can automatically ignore equation images.
I think the author of JUMultithumb should learn something from MultiThumb, if it is possible, please take over the MultiThumb code and continue it, because that project seems been abandoned by its author.
For the equation image issue, you also can add a new option to solve it. This option is: exclude images with "nothumbnail" CSS class name.
the only disadvantage is that the author did not add multi-language for it. Hope he will add a /language folder soon.
Language folder now added.
Finally, after the email exchange with the author, I found out how to modify those code. I think the author should include that link to the forum post in the extension description.
Though this is a good extension, I think modifying core files is not good.