Growing size of UI*Label.xml files
Locked
Growing size of UI*Label.xml files
 
|
Maybe it is just me, but it seems that the UI*Labels.xml files in the
configuration are becoming more cumbersome to manage and that it takes more and more time to process in OFBiz with each commit iteration. Currently all translations in each individual component is handled through distinct files for UI, errors and entities. And some are growing quite large, e.g. the Ui*Labels.xml file in the PRODUCT components is already over 30k lines. Should we not rethink our strategy how localization is handled? E.g. have a file fore the en_x derivate as the basis for all other translations and for each language variant a separate file? We could even consider the https://translate.apache.org/ solution to use as the tool to do maintenance and management of the translations. What do you think? Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
Re: Growing size of UI*Label.xml files
|
|
The label files can be split out to separate languages, but the new
files will need to be in the original Java *.properties or *.xml formats. Adrian Crum Sandglass Software www.sandglass-software.com On 10/3/2014 12:21 PM, Pierre Smits wrote: > Maybe it is just me, but it seems that the UI*Labels.xml files in the > configuration are becoming more cumbersome to manage and that it takes more > and more time to process in OFBiz with each commit iteration. > > Currently all translations in each individual component is handled through > distinct files for UI, errors and entities. And some are growing quite > large, e.g. the Ui*Labels.xml file in the PRODUCT components is already > over 30k lines. > > Should we not rethink our strategy how localization is handled? E.g. have a > file fore the en_x derivate as the basis for all other translations and for > each language variant a separate file? > > We could even consider the https://translate.apache.org/ solution to use as > the tool to do maintenance and management of the translations. > > What do you think? > > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > |
Re: Growing size of UI*Label.xml files
|
|
Looking at the tool(s) behind http://translate.apache.org, being pootle and
the translation toolkit I see that it supports both. Though the xml file is in the XLIFF format, which is different to ours. For more info see: https://en.wikipedia.org/wiki/Pootle https://en.wikipedia.org/wiki/Translate_Toolkit https://en.wikipedia.org/wiki/XLIFF Regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Oct 3, 2014 at 1:44 PM, Adrian Crum < [hidden email]> wrote: > The label files can be split out to separate languages, but the new files > will need to be in the original Java *.properties or *.xml formats. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 10/3/2014 12:21 PM, Pierre Smits wrote: > >> Maybe it is just me, but it seems that the UI*Labels.xml files in the >> configuration are becoming more cumbersome to manage and that it takes >> more >> and more time to process in OFBiz with each commit iteration. >> >> Currently all translations in each individual component is handled through >> distinct files for UI, errors and entities. And some are growing quite >> large, e.g. the Ui*Labels.xml file in the PRODUCT components is already >> over 30k lines. >> >> Should we not rethink our strategy how localization is handled? E.g. have >> a >> file fore the en_x derivate as the basis for all other translations and >> for >> each language variant a separate file? >> >> We could even consider the https://translate.apache.org/ solution to use >> as >> the tool to do maintenance and management of the translations. >> >> What do you think? >> >> >> Pierre Smits >> >> *ORRTIZ.COM <http://www.orrtiz.com>* >> Services & Solutions for Cloud- >> Based Manufacturing, Professional >> Services and Retail & Trade >> http://www.orrtiz.com >> >> |
|
In reply to this post by Adrian Crum-3
It seems like breaking up the UI Label files into multiple languages means entering the same key into multiple files each with its own translation. This increases the probability of human error. I would much rather have a single key with all translations of that key in one place.
It seems to me like a cleaner approach _if_ we need to break a file into multiple files is to do so by subcategorizing the labels. For example, in accounting, you have a file for InvoiceUiLabels.xml, PaymentUiLabels.xml, AgreementUiLabels.xml, GlUiLabels.xml and so on. However, I personally do not see a problem with having large translation files. These files are very simple and easy to maintain, not like source code files. Furthermore, I would find the following disadvantages from breaking these files down: - First, we will have many more imports into the screens and common screens of the different components - If I am not sure where a translation is supposed to reside in, I would have to hunt it down in many files instead of one - It also increases the probability of duplication which already exists in these monolithic UI files without breaking them down. I think this would only get worse with smaller and smaller files and reusing labels becomes less efficient. My 2 cents Taher Alkhateeb ----- Original Message ----- From: "Adrian Crum" <[hidden email]> To: [hidden email] Sent: Friday, 3 October, 2014 2:44:52 PM Subject: Re: Growing size of UI*Label.xml files The label files can be split out to separate languages, but the new files will need to be in the original Java *.properties or *.xml formats. Adrian Crum Sandglass Software www.sandglass-software.com On 10/3/2014 12:21 PM, Pierre Smits wrote: > Maybe it is just me, but it seems that the UI*Labels.xml files in the > configuration are becoming more cumbersome to manage and that it takes more > and more time to process in OFBiz with each commit iteration. > > Currently all translations in each individual component is handled through > distinct files for UI, errors and entities. And some are growing quite > large, e.g. the Ui*Labels.xml file in the PRODUCT components is already > over 30k lines. > > Should we not rethink our strategy how localization is handled? E.g. have a > file fore the en_x derivate as the basis for all other translations and for > each language variant a separate file? > > We could even consider the https://translate.apache.org/ solution to use as > the tool to do maintenance and management of the translations. > > What do you think? > > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > |
Re: Growing size of UI*Label.xml files
|
|
For sure, there are many options possible. And yes, having theme specific
translation files could be a good solution to avoid duplications as much as possible. The idea behind this topic is to increase the adoption of OFBiz, allowing more people to contribute to the translations without having to go through JIRA issues creation, filing patches, reviewing patch files, etc. While at the same time decreasing the workload of the committers regarding handling these patches. Regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Oct 3, 2014 at 2:00 PM, Taher Alkhateeb <[hidden email]> wrote: > It seems like breaking up the UI Label files into multiple languages means > entering the same key into multiple files each with its own translation. > This increases the probability of human error. I would much rather have a > single key with all translations of that key in one place. > > It seems to me like a cleaner approach _if_ we need to break a file into > multiple files is to do so by subcategorizing the labels. For example, in > accounting, you have a file for InvoiceUiLabels.xml, PaymentUiLabels.xml, > AgreementUiLabels.xml, GlUiLabels.xml and so on. > > However, I personally do not see a problem with having large translation > files. These files are very simple and easy to maintain, not like source > code files. Furthermore, I would find the following disadvantages from > breaking these files down: > > - First, we will have many more imports into the screens and common > screens of the different components > - If I am not sure where a translation is supposed to reside in, I would > have to hunt it down in many files instead of one > - It also increases the probability of duplication which already exists in > these monolithic UI files without breaking them down. I think this would > only get worse with smaller and smaller files and reusing labels becomes > less efficient. > > My 2 cents > > Taher Alkhateeb > > ----- Original Message ----- > > From: "Adrian Crum" <[hidden email]> > To: [hidden email] > Sent: Friday, 3 October, 2014 2:44:52 PM > Subject: Re: Growing size of UI*Label.xml files > > The label files can be split out to separate languages, but the new > files will need to be in the original Java *.properties or *.xml formats. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 10/3/2014 12:21 PM, Pierre Smits wrote: > > Maybe it is just me, but it seems that the UI*Labels.xml files in the > > configuration are becoming more cumbersome to manage and that it takes > more > > and more time to process in OFBiz with each commit iteration. > > > > Currently all translations in each individual component is handled > through > > distinct files for UI, errors and entities. And some are growing quite > > large, e.g. the Ui*Labels.xml file in the PRODUCT components is already > > over 30k lines. > > > > Should we not rethink our strategy how localization is handled? E.g. > have a > > file fore the en_x derivate as the basis for all other translations and > for > > each language variant a separate file? > > > > We could even consider the https://translate.apache.org/ solution to > use as > > the tool to do maintenance and management of the translations. > > > > What do you think? > > > > > > Pierre Smits > > > > *ORRTIZ.COM <http://www.orrtiz.com>* > > Services & Solutions for Cloud- > > Based Manufacturing, Professional > > Services and Retail & Trade > > http://www.orrtiz.com > > > > |
Re: Growing size of UI*Label.xml files
|
|
In my opinion we should start considering the idea of keeping the English labels by default in the system (trunk and releases) and distribute separately the "language packs" (from the download page and/or with special ant targets).
Jacopo On Oct 3, 2014, at 2:16 PM, Pierre Smits <[hidden email]> wrote: > For sure, there are many options possible. And yes, having theme specific > translation files could be a good solution to avoid duplications as much as > possible. > > The idea behind this topic is to increase the adoption of OFBiz, allowing > more people to contribute to the translations without having to go through > JIRA issues creation, filing patches, reviewing patch files, etc. While at > the same time decreasing the workload of the committers regarding handling > these patches. > > Regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Fri, Oct 3, 2014 at 2:00 PM, Taher Alkhateeb <[hidden email]> > wrote: > >> It seems like breaking up the UI Label files into multiple languages means >> entering the same key into multiple files each with its own translation. >> This increases the probability of human error. I would much rather have a >> single key with all translations of that key in one place. >> >> It seems to me like a cleaner approach _if_ we need to break a file into >> multiple files is to do so by subcategorizing the labels. For example, in >> accounting, you have a file for InvoiceUiLabels.xml, PaymentUiLabels.xml, >> AgreementUiLabels.xml, GlUiLabels.xml and so on. >> >> However, I personally do not see a problem with having large translation >> files. These files are very simple and easy to maintain, not like source >> code files. Furthermore, I would find the following disadvantages from >> breaking these files down: >> >> - First, we will have many more imports into the screens and common >> screens of the different components >> - If I am not sure where a translation is supposed to reside in, I would >> have to hunt it down in many files instead of one >> - It also increases the probability of duplication which already exists in >> these monolithic UI files without breaking them down. I think this would >> only get worse with smaller and smaller files and reusing labels becomes >> less efficient. >> >> My 2 cents >> >> Taher Alkhateeb >> >> ----- Original Message ----- >> >> From: "Adrian Crum" <[hidden email]> >> To: [hidden email] >> Sent: Friday, 3 October, 2014 2:44:52 PM >> Subject: Re: Growing size of UI*Label.xml files >> >> The label files can be split out to separate languages, but the new >> files will need to be in the original Java *.properties or *.xml formats. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 10/3/2014 12:21 PM, Pierre Smits wrote: >>> Maybe it is just me, but it seems that the UI*Labels.xml files in the >>> configuration are becoming more cumbersome to manage and that it takes >> more >>> and more time to process in OFBiz with each commit iteration. >>> >>> Currently all translations in each individual component is handled >> through >>> distinct files for UI, errors and entities. And some are growing quite >>> large, e.g. the Ui*Labels.xml file in the PRODUCT components is already >>> over 30k lines. >>> >>> Should we not rethink our strategy how localization is handled? E.g. >> have a >>> file fore the en_x derivate as the basis for all other translations and >> for >>> each language variant a separate file? >>> >>> We could even consider the https://translate.apache.org/ solution to >> use as >>> the tool to do maintenance and management of the translations. >>> >>> What do you think? >>> >>> >>> Pierre Smits >>> >>> *ORRTIZ.COM <http://www.orrtiz.com>* >>> Services & Solutions for Cloud- >>> Based Manufacturing, Professional >>> Services and Retail & Trade >>> http://www.orrtiz.com >>> >> >> |
Re: Growing size of UI*Label.xml files
|
|
Whether or not this community should opt for just one language pack in
releases should be decided by the entire community. Let's discuss that in the user mailing list. But consensus on that subject will be expedited when we can ensure that users (and even release managers with respect to multiple language packs in releases) can get/integrate additional language packs in the easiest way possible. Is externalizing translation maintenance to e.g. translate.apache.org and incorporating the generated translation packs/files through ant/gradle targets technical feasible given the difference in xml format? Including getting the files from that repository? Having as much automation in this process is best for all... When we are not certain of this, we might conduct an experiment Don't you agree? Regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Oct 3, 2014 at 2:57 PM, Jacopo Cappellato < [hidden email]> wrote: > In my opinion we should start considering the idea of keeping the English > labels by default in the system (trunk and releases) and distribute > separately the "language packs" (from the download page and/or with special > ant targets). > > Jacopo > > > On Oct 3, 2014, at 2:16 PM, Pierre Smits <[hidden email]> wrote: > > > For sure, there are many options possible. And yes, having theme specific > > translation files could be a good solution to avoid duplications as much > as > > possible. > > > > The idea behind this topic is to increase the adoption of OFBiz, allowing > > more people to contribute to the translations without having to go > through > > JIRA issues creation, filing patches, reviewing patch files, etc. While > at > > the same time decreasing the workload of the committers regarding > handling > > these patches. > > > > Regards, > > > > Pierre Smits > > > > *ORRTIZ.COM <http://www.orrtiz.com>* > > Services & Solutions for Cloud- > > Based Manufacturing, Professional > > Services and Retail & Trade > > http://www.orrtiz.com > > > > On Fri, Oct 3, 2014 at 2:00 PM, Taher Alkhateeb < > [hidden email]> > > wrote: > > > >> It seems like breaking up the UI Label files into multiple languages > means > >> entering the same key into multiple files each with its own translation. > >> This increases the probability of human error. I would much rather have > a > >> single key with all translations of that key in one place. > >> > >> It seems to me like a cleaner approach _if_ we need to break a file into > >> multiple files is to do so by subcategorizing the labels. For example, > in > >> accounting, you have a file for InvoiceUiLabels.xml, > PaymentUiLabels.xml, > >> AgreementUiLabels.xml, GlUiLabels.xml and so on. > >> > >> However, I personally do not see a problem with having large translation > >> files. These files are very simple and easy to maintain, not like source > >> code files. Furthermore, I would find the following disadvantages from > >> breaking these files down: > >> > >> - First, we will have many more imports into the screens and common > >> screens of the different components > >> - If I am not sure where a translation is supposed to reside in, I would > >> have to hunt it down in many files instead of one > >> - It also increases the probability of duplication which already exists > in > >> these monolithic UI files without breaking them down. I think this would > >> only get worse with smaller and smaller files and reusing labels becomes > >> less efficient. > >> > >> My 2 cents > >> > >> Taher Alkhateeb > >> > >> ----- Original Message ----- > >> > >> From: "Adrian Crum" <[hidden email]> > >> To: [hidden email] > >> Sent: Friday, 3 October, 2014 2:44:52 PM > >> Subject: Re: Growing size of UI*Label.xml files > >> > >> The label files can be split out to separate languages, but the new > >> files will need to be in the original Java *.properties or *.xml > formats. > >> > >> Adrian Crum > >> Sandglass Software > >> www.sandglass-software.com > >> > >> On 10/3/2014 12:21 PM, Pierre Smits wrote: > >>> Maybe it is just me, but it seems that the UI*Labels.xml files in the > >>> configuration are becoming more cumbersome to manage and that it takes > >> more > >>> and more time to process in OFBiz with each commit iteration. > >>> > >>> Currently all translations in each individual component is handled > >> through > >>> distinct files for UI, errors and entities. And some are growing quite > >>> large, e.g. the Ui*Labels.xml file in the PRODUCT components is already > >>> over 30k lines. > >>> > >>> Should we not rethink our strategy how localization is handled? E.g. > >> have a > >>> file fore the en_x derivate as the basis for all other translations and > >> for > >>> each language variant a separate file? > >>> > >>> We could even consider the https://translate.apache.org/ solution to > >> use as > >>> the tool to do maintenance and management of the translations. > >>> > >>> What do you think? > >>> > >>> > >>> Pierre Smits > >>> > >>> *ORRTIZ.COM <http://www.orrtiz.com>* > >>> Services & Solutions for Cloud- > >>> Based Manufacturing, Professional > >>> Services and Retail & Trade > >>> http://www.orrtiz.com > >>> > >> > >> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |