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 < jacopo.cappell...@hotwaxmedia.com> 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 <pierre.sm...@gmail.com> 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 < > slidingfilame...@gmail.com> > > 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" <adrian.c...@sandglass-software.com> > >> To: dev@ofbiz.apache.org > >> 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 > >>> > >> > >> > >
