|
From: | Yannick Warnier |
Subject: | [Dolibarr-dev] Language terms duplication |
Date: | Sun, 12 Jul 2015 13:43:53 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
Hi, Sorry to be asking a series of unpleasing questions, but I'm realizing, translating language variables, that there is a lot of duplication of terms. For example "Last supplier's invoices" (and a series of incorrect variations) appear in several different files (I also count InvoiceDeletedDolibarr, Customer, This reveals an issue that we just recently fixed in Chamilo: multiple language files might not really be as beneficial as they may seem. These were the issues with multiple files that we think we have solved my moving everything to one file in Chamilo. 1. opening files (I/O) is expensive (although the expense can be reduced by opcode caching files, we have to assume that not all Dolibarr setups use opcode cache) 2. the decision of which files to include is complex for the system (part of Translate::Load() if I'm not mistaken) 3. the decision of which files to include is complex for the developer (if he wants *just one* term from another file, he needs to include the whole file - if this is "admin", then he needs to include 1600 terms) 4. gettext (the only real standard in terms of translations) doesn't play too well with multiple files 5. there is some level of duplication, because people do not look at all files, which also means translators have to translate the same thing several times, with the doubt of having seen that variable someplace else. On the other side, advantages of multiple language files are only: 1. Reducing the number of variables stored in memory for any given script loaded 2. Giving meaning to language terms (because they are in such or such file, then they are obviously meaning something more specific) I'm not asking for a straight answer but I'd like more information on that, to know if this is something that is continued from the past, or if it has been reconsidered recently. Cheers, Yannick |
[Prev in Thread] | Current Thread | [Next in Thread] |