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