Foros de discusión

Ext plugin and directly modifying source code

thumbnail
Hitoshi Ozawa, modificado hace 13 años.

Ext plugin and directly modifying source code

Liferay Legend Mensajes: 7942 Fecha de incorporación: 24/03/10 Mensajes recientes
I was wondering how people are creating a localized version of Liferay.

It's possible to offer localized code using ext plugin, but ext plugin cannot overlap. That is, if I offer a localized code by using ext plugin, I won't be able to customized the localized code for a particular user. This may not seems like a major problem at first, but it also means I won't be able to "upgrade" the localization because I'm not able to "redeploy" - I have to manually "undeploy" the localization ext plugin before I can update the new localization ext plugin. This is even more problematic when there is a "bug fix" ext plugin for localized classes and I can't deploy it because there already is an ext plugin for the class.

Ext plugin also actually installs itself into the Liferay war package after deployment and "undeploying" just the section to be upgraded may not be all that easy.

The only advantage I can think of to use an ext plugin to offer localization is the license - I won't be required to offer the localization source code to users.

Would appreciate ideas and any other comment on using ext plugin to localize Liferay.
thumbnail
Olaf Kock, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 6396 Fecha de incorporación: 23/09/08 Mensajes recientes
You should rather use Hook plugins for Language/Localization modifications.

Of course, in the long run, please make sure to feed back your translations so that they are included in the next version and you need to patch less and less localization strings with each version.
thumbnail
Hitoshi Ozawa, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 7942 Fecha de incorporación: 24/03/10 Mensajes recientes
Can I overwrite impl classes with hooks?
thumbnail
Julio Camarero, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 1668 Fecha de incorporación: 15/07/08 Mensajes recientes
No, that is not supported Hitoshi. But you can overwrite existing language keys or even add new ones, have a look at the link provided by Olaf for more information.

If you want your improvements to appear in the next release (6.0.6) so that you have less strings to patch, please, make sure to submit your improvements before February 11th.

Thanks a lot!
thumbnail
Hitoshi Ozawa, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 7942 Fecha de incorporación: 24/03/10 Mensajes recientes
Julio Camarero:
No, that is not supported Hitoshi. But you can overwrite existing language keys or even add new ones, have a look at the link provided by Olaf for more information.


Having localization codes in both hooks and ext plugin is just a mess and very prone to error.
thumbnail
Olaf Kock, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 6396 Fecha de incorporación: 23/09/08 Mensajes recientes
Hitoshi Ozawa:
Having localization codes in both hooks and ext plugin is just a mess and very prone to error.


What type of code do you need to be in ext? What kind of problem does it solve? Maybe there's another way to solve the same problem that can be tackled in a hook.
thumbnail
Hitoshi Ozawa, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 7942 Fecha de incorporación: 24/03/10 Mensajes recientes
Olaf Kock:
What type of code do you need to be in ext? What kind of problem does it solve? Maybe there's another way to solve the same problem that can be tackled in a hook.


As I stated above, classes under impl. Anyways, what's the conflict resolution with hooks? For example, if the localization modified a model and an user want to further modify a model, it is possible to specify the order which hooks should be loaded?
I hope you're not going to suggest to modified the localization hook because this would be mess trying to upgrade several users each with slight different modifications.

The major factor to consider is how to make it easier for local end user developers to customize Liferay. Another factor is time - I don't want to wait months and year.

I'm currently working on documents because I want more people to know more about Liferay.
I currently have a workable localized version, but will try to close the difference with Liferay.com version when I have more time.
thumbnail
Olaf Kock, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 6396 Fecha de incorporación: 23/09/08 Mensajes recientes
well, the order hooks are deployed is undefined. I haven't checked, but I believe that Language.properties overloads are per item, so you can have multiple hooks providing new Language_xx.properties for your language (repeat: I have not checked). What entry wins when you modify the same entry in various files though is probably undefined.

But if you want these translations, it should more or less not-matter, which entry wins. I know that this is probably more pragmatic than you like, but remember: It's just my assumption about the behaviour. Somebody with some actual knowledge should confirm or deny this assumption.

For now I won't make any comments regarding the implementation of other classes for i18n fixes, I probably don't have the correct usage pattern in mind and would hunt for the wrong solution.
thumbnail
Jonathon Omahen, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Junior Member Mensajes: 31 Fecha de incorporación: 28/09/09 Mensajes recientes
Hitoshi Ozawa:
Olaf Kock:
What type of code do you need to be in ext? What kind of problem does it solve? Maybe there's another way to solve the same problem that can be tackled in a hook.


As I stated above, classes under impl. Anyways, what's the conflict resolution with hooks? For example, if the localization modified a model and an user want to further modify a model, it is possible to specify the order which hooks should be loaded?
I hope you're not going to suggest to modified the localization hook because this would be mess trying to upgrade several users each with slight different modifications.

The major factor to consider is how to make it easier for local end user developers to customize Liferay. Another factor is time - I don't want to wait months and year.

I'm currently working on documents because I want more people to know more about Liferay.
I currently have a workable localized version, but will try to close the difference with Liferay.com version when I have more time.


Ozawaさん,


Could you be more explicit? What models and *Impl classes do you need to modify for localisation? I understand that some things, such as web forms and such, need to be modified (which can be done through JSP overrides in hooks). But I'm not seeing what it is in *Impl that needs to be edited?

My feeling is that if we have to make any substantial modifications to the source, outside of Language_*.properties and a few JSPs, then we need to think more closely about how we handle those items in Liferay.

Thoughts?


ご連絡をお待ちしています。
thumbnail
Hitoshi Ozawa, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 7942 Fecha de incorporación: 24/03/10 Mensajes recientes
I've already suggested about having a different localized Liferay version several times.
Since Liferay was taking too much time, I've already developed a Japanese localized version of liferay and the source is available from my site: google oss ja jpn
I've actually modified a little bit more but hasn't had a time to release it yet.
There is a source and I've fixed the bundled packages directly after that. Unfortunately, it seems Liferay's build does not properly handle encoding correctly and I have to apply some patch the bundled package directly.

I just want to warn other that using ext plugin for localization is a bad idea with the current Liferay version because of ext plugin limitations unless the localization is just for an user.

I appreciate Liferay for fine work they have done but I'm not going to spend my time arguing too much on each topic to get localization properly supported by Liferay.com.

BTW, thanks for adding "日本語" to the Language menu. I'm able to find more mistranslations while using this forum.
thumbnail
Jonathon Omahen, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Junior Member Mensajes: 31 Fecha de incorporación: 28/09/09 Mensajes recientes
Hitoshi Ozawa:

I appreciate Liferay for fine work they have done but I'm not going to spend my time arguing too much on each topic to get localization properly supported by Liferay.com.

BTW, thanks for adding "日本語" to the Language menu. I'm able to find more mistranslations while using this forum.


I appreciate your work as well, and the more voices that call out for better localisation support, the quicker it can be worked into the product.

As far as custom versions of Liferay, my belief is that the core product should have a flexible enough i18n/l10n support to avoid the need for hooks/ext/repackaged distributions.

Also, many of the translations on the 日本語 setting seem to not be completely up-to-date, which you know if you're using the latest CE as well. We always appreciate the hard work and sharp eye of community members like you helping refine the translations to be more professional.


I hope you'll consider submitting improvements on the translation. emoticon

宜しくお願い致します。
thumbnail
Hitoshi Ozawa, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 7942 Fecha de incorporación: 24/03/10 Mensajes recientes
I submission procedure is being the bottle neck for me - it's requires too much time.
I often find translation problems while I'm using it and I can just update my copy on my machine and able to upload a new version at my site. For instance, I just find one today while looking at my event log (attached image). I find some yesterday too. Since I'm not given a svn account to a trunk, I have to submit the property file to jira each time.

I'm also usually working on Japanese MS Windows machine (XP, Vista, 7) and they all use Shift JIS. Since Liferay source often does not contain BOM or encoding, files are opened up as Shift JIS. Same with the compile. It's a hassle to convert encoding each time to submit and then to used the downloaded source.

Furthermore, I'm not exactly certain if the fix I've submitted will be applied to the build and when it will be applied to the trunk.

I'm making all the modifications public and liferay is very welcomed to use them. Liferay's current procedure is just to much of a hassle for me to submit every time - if you were not Liferay's employee, would you submit to Liferay's jira? May be once in a while, but not when it's very often.

Archivos adjuntos:

thumbnail
Olaf Kock, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 6396 Fecha de incorporación: 23/09/08 Mensajes recientes
Hitoshi Ozawa:
Furthermore, I'm not exactly certain if the fix I've submitted will be applied to the build and when it will be applied to the trunk.


Hi,

the way I've got involved with giving back to Liferay is exactly through l10n - at least this was the first part I contributed back. I seem to be lucky though that it was in german, where problems are relatively rare and rather around ambiguities around the english language (do I translate this as a verb, a noun or as a command? e.g. the missing context that you mentioned)

Hitoshi Ozawa:
I'm making all the modifications public and liferay is very welcomed to use them. Liferay's current procedure is just to much of a hassle for me to submit every time - if you were not Liferay's employee, would you submit to Liferay's jira? May be once in a while, but not when it's very often.


The way I handled this was to submit in larger chunks - e.g. it's not necessary go submit each single entry. The milestones when it'd help are announced here and especially just before releases it pays to go for i18n issues - at least in Language_xx.properties.

With i18n-related code changes I'm not sure as I'm not involved in that a lot. However, my former questions about what implementation classes you need to change were not meant to push back on that, but curious. I want to learn more about the problems that i18n of such a product has. Thinking back about these, there are several ambiguities that probably need code changes for the german translation as well.

However, sadly we can't "just" pick up what you publish on your site: When you submit an issue and patch to jira you're effectively licensing the changes to us for inclusion in the product.

If the whole Jira workflow is too much of a hassle for you, mentioning your issues here might be a low-intensity way to work around that. But then - you're already doing that.

Thanks so far for bringing up the issues. Please keep it up. Liferay can only get better with such input.
thumbnail
Hitoshi Ozawa, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 7942 Fecha de incorporación: 24/03/10 Mensajes recientes
If it's just a superficial change such as model change and associated jsp change, I'm not writing up a jira, but I am writing up a jira of critical errors I find that would prevent users from using Liferay and providing a solution when possible.

Example:

http://issues.liferay.com/browse/LPS-14801?page=com.atlassian.jira.plugin.system.issuetabpanels%3Achangehistory-tabpanel

http://vm-3.liferay.com/browse/LPS-14786?focusedCommentId=123321&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel

In the other projects which I'm involved in such as MuleSoft and JasperSoft, they've given me an account on their development svn. I think they have a different set of svn for enterprise version development and filtering codes when syncing code from the development svn. It's unfortunate that Liferay has a different policy.

Also, I'm actually skipping I18N and just doing L10N for Japanese to reduce development time to market. I18N is very extensive and would require a lot of time.
Example:
Providing Japanese names for default roles and pages are much easier done by just translating the English names or inserting the Japanese names into the source code.
thumbnail
Mika Koivisto, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 1519 Fecha de incorporación: 7/08/06 Mensajes recientes
Just wanted to let you know that we are in the process of moving trunk development to Github. That should make it easier for contributing to Liferay.
thumbnail
Hitoshi Ozawa, modificado hace 13 años.

RE: Ext plugin and directly modifying source code

Liferay Legend Mensajes: 7942 Fecha de incorporación: 24/03/10 Mensajes recientes
Mika Koivisto:
Just wanted to let you know that we are in the process of moving trunk development to Github. That should make it easier for contributing to Liferay.


That's good news.