Menu
▾
▴
Re: [WebERP-developers] long description translation
|
From: Rafael C. <raf...@gm...> - 2014-12-29 07:53:43
|
Hi Ricard, I saw your commit. Thank you for your work! I modify the boolean field "needrevision" to a tiny_integer with a maximum_display_width of 1, signed and not_null. This reduces the storage from 4 Bytes to 1 Byte per record (saves disk space, data transmission and mysql-cache). Ref: http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html. If we are not going to use the benefits of "null", I suggest to delete the null attribute in both descriptions. Best regards, Rafael. 2014-12-24 13:46 GMT-06:00 Rafael Chacón <raf...@gm...>: > Hi Ricard, > > I was thing on control of documents (ISO 9001, 4.2.3). Field "LastUpdate", > also called "version" or "last version", has more the meaning of when was > did (and was approved) the latest revision. How often procedures, politics, > specifications, product descriptions, etc. change depends on the company. > E.g. (for products) writing improvements of description (usually marketing > or legal), new product features ("our management software now includes a > financial scorecard"), new uses ("our chlorine substitute can be used with > our biodegradable detergent for cleaning, bleaching and disinfecting > clothing") newly discovered contraindications ("must not be used with... or > by..."), new conditions of service, etc. > > Sorry, when I sent code lines it is to show that if we have several > languages, the html page becomes very long (see enclosed image with three > languages). [Probably better to show two description depending on a > language drop-down-menu ?]. > > Ok. I will commit changes. I agree with you, I would like to hear other > opinions to make the most useful code. > > (*) English and French by Google Translations API without human. It > speed-up the translation procedure (human step it easier). Nice job!! > > Best regards, Rafael. > > 2014-12-24 1:11 GMT-06:00 Pak Ricard <pak...@gm...>: > > Hi Rafael: >> >> Seems like a good idea to keep also dates. Not sure if it's useful for >> mainstream webERP, as (from my POV) seems reasonable that items have the >> same description during their lifetime. I can't see a reason for a >> description to become obsolete. I mean, if description can become obsolete, >> why not item sizes, or pan sizes, or category or any other item detail? >> >> Probably we should read more developer's POV on this issue, before >> heading this way. Maybe I'm wrong and more people find this approach >> mainstream, and then, we should follow it. Anyway, as you might know, >> webERP is a "do-ocracy" :-) >> >> Regarding revision... I'm afraid I'm not a good choice to revise someone >> else's code, I'm struggling to commit "reasonable" code myself. Probably >> Phil, Tim, Exson or any other developer with good coding skills can check >> it out much better than myself. >> >> >> >> Regards, >> Ricard >> >> 2014-12-23 22:52 GMT+08:00 Rafael Chacón <raf...@gm...> >> : >> >>> Hi Ricard, >>> >>> Yes, you are right. A lastupdate field is required in stockmaster for >>> two reasons: (1) If we keep description and longdescription in stockmaster; >>> (2) For version purposes (document control). >>> >>> Sorry, I used datetime(14) in lastupdate because I was thing on control >>> of documents (ISO 9001, 4.2.3). We use document_age ($Today - $LastUpdate > >>> $MaxAge) for all documents to automatically flag a revision needed. Also, >>> for documents in several languages (multilingual companies), we use >>> age_difference between translations ($LastVersion - $LastUpdate > $MaxDif) >>> to automatically flag a revision needed. This automatically flag is used as >>> a "backup" if the update producedure is not completed (e.g. someone lasts >>> in a document in a series; someone lasts in a translation in a group). >>> >>> We can use a TinyInteger(1) for revisionneeded, or the NULL value on >>> lastupdate to set the flag a revision is needed. >>> >>> If you agree, I will send you the code I have (I have to modify from use >>> stockdescription -> stockdescriptiontranslations; and the all the >>> descriptions are in one table). The main problem (for me) is in Stocks.php: >>> if we have several languages, the html page become very long. See this: >>> >>> ... >>> $_POST['ShrinkFactor'] = $myrow['shrinkfactor']; >>> >>> $sql = "SELECT language_id, descriptiontranslation, longdescription, >>> lastupdate FROM stockdescriptiontranslations WHERE stockid='" . $StockID >>> . "' AND ("; >>> foreach ($ItemDescriptionLanguagesArray as $LanguageId) { >>> ... >>> >>> ... >>> $_POST['Description_' . >>> str_replace('.','_',$myrow['language_id'])] = >>> $myrow['descriptiontranslation']; >>> $_POST['LongDescription_' . >>> str_replace('.','_',$myrow['language_id'])] = $myrow['longdescription']; >>> $_POST['LastUpdate_' . >>> str_replace('.','_',$myrow['language_id'])] = $myrow['lastupdate']; >>> } >>> ... >>> >>> ... >>> if (isset($_POST['Description'])) { >>> $Description = $_POST['Description']; >>> } else { >>> $Description =''; >>> } >>> echo '<tr> >>> <td>' . _('Part Description') . ' (' . _('short') . '):</td> >>> <td><input ' . (in_array('Description',$Errors) ? >>> 'class="inputerror"' : '' ) .' type="text" ' . >>> ($New==0?'autofocus="autofocus"':'') . ' maxlength="50" name="Description" >>> required="required" size="52" value="' . stripslashes($Description) . '" >>> /></td> >>> </tr>'; >>> >>> if (isset($_POST['LongDescription'])) { >>> $LongDescription = AddCarriageReturns($_POST['LongDescription']); >>> } else { >>> $LongDescription =''; >>> } >>> >>> echo ' >>> <tr> >>> <td>' . _('Part Description') . ' (' . _('long') . '):</td> >>> <td><textarea ' . (in_array('LongDescription',$Errors) ? >>> 'class="texterror"' : '' ) .' name="LongDescription" cols="40" rows="3">' >>> . stripslashes($LongDescription) . '</textarea></td> >>> </tr> >>> <tr> >>> <td><hr /></td> >>> <td><hr /></td> >>> </tr>'; >>> >>> foreach ($ItemDescriptionLanguagesArray as $LanguageId) { >>> if ($LanguageId!=''){ >>> //unfortunately cannot have points in POST variables so have to >>> mess with the language id >>> $PostVariableName = 'Description_' . >>> str_replace('.','_',$LanguageId); >>> $LongDescription_Name = 'LongDescription_' . >>> str_replace('.','_',$LanguageId); >>> $LastUpdate_Name = 'LastUpdate_' . >>> str_replace('.','_',$LanguageId); >>> if (!isset($_POST[$PostVariableName])){ >>> $_POST[$PostVariableName] =''; >>> } >>> echo ' >>> <tr> >>> <td>' . _('Language') . ':</td> >>> <td>' . >>> $LanguagesArray[$LanguageId]['LanguageName'].'</td> >>> </tr> >>> <tr> >>> <td><label for="'. $PostVariableName . '">' . _('Part >>> Description') . ' (' . _('short') . '):</label></td> >>> <td><input id="'. $PostVariableName . '" maxlength="50" >>> name="'. $PostVariableName . '" size="52" title="' . _('This language >>> translation of the item will be used in invoices and credits to customers >>> who are defined to use this language. The language translations to maintain >>> here can be configured in the system parameters page') . '" type="text" >>> value="' . $_POST[$PostVariableName] . '" /></td> >>> </tr> >>> <tr> >>> <td>' . _('Part Description') . ' (' . _('long') . >>> '):</td> >>> <td><textarea id="'. $LongDescription_Name . '" name="'. >>> $LongDescription_Name . '" cols="40" rows="3">' . >>> stripslashes($_POST[$LongDescription_Name]) . '</textarea></td> >>> </tr> >>> <tr> >>> <td>' . _('Last update') . ':</td> >>> <td>'. $_POST[$LastUpdate_Name]; >>> /* $LastUpdate = $_POST[$LastUpdate_Name]; >>> if($Today - $LastUpdate > $MaxAge) { echo _('WARNING: This >>> description may be obsolete.');} >>> if($Today - $LastUpdate > $MaxAge) { echo _('WARNING: This >>> translation may be obsolete.');} >>> if(empty($LastUpdate)) { echo _('WARNING: this description is >>> obsolete.');}*/ >>> echo ' >>> </td> >>> </tr> >>> <tr> >>> <td><hr /></td> >>> <td><hr /></td> >>> </tr> >>> '; >>> } >>> } >>> >>> >>> echo ' >>> <tr> >>> <td>' . _('Image File (.jpg)') . ':</td> >>> ... >>> >>> >>> Best regards, Rafael. >>> >>> 2014-12-22 2:07 GMT-06:00 Pak Ricard <pak...@gm...>: >>> >>> Hi: >>>> >>>> Thanks Rafael for allthese details. >>>> >>>> I've chking your SQL changes and I think: >>>> lastupdate field. If type is datetime, we must have a datetime also for >>>> description and ,longdescription in stockmaster, to be able to compare both >>>> dates to decide which records need revision and which records do not. >>>> >>>> To me, it's easier to not use "lastupdate" but a INT(1) called >>>> revisionneeded. We can easily set this flag to TRUE when creating or >>>> modifying the descriptions in Stocks.php. Then it's very easy to create a >>>> script for later revision of translations and select the records needing >>>> revision, not all of them. >>>> >>>> If it's Ok with you, I could code stocks.php to allow these new fields >>>> and we could start working from there. >>>> >>>> >>>> Regards, >>>> Ricard >>>> >>>> 2014-12-22 4:06 GMT+08:00 Rafael Chacón <raf...@gm... >>>> >: >>>> >>>>> Hi, >>>>> >>>>> Sorry by the delay. >>>>> >>>>> * Ok. Modifications in stockdescriptiontranslations may or may not be >>>>> used to store the item descriptions in the default language. We can work on >>>>> any of both codes. >>>>> >>>>> * If we concentrate all descriptions in a single table, to prevent a >>>>> script fails (because we forgot to update it), we can leave the fields (in >>>>> stockmaster) without dropping in this version (Comment). In both cases >>>>> (concentrated or not), it is one query. E.g. (changes in bold): >>>>> >>>>> $Query = " >>>>> SELECT >>>>> stockmaster.stockid, >>>>> >>>>> * stockdescriptiontranslations.descriptiontranslation, >>>>> stockdescriptiontranslations.longdescription,* >>>>> stockmaster.categoryid, >>>>> stockmaster.units, >>>>> stockmaster.mbflag, >>>>> stockmaster.discontinued, >>>>> stockmaster.controlled, >>>>> stockmaster.serialised, >>>>> stockmaster.perishable, >>>>> stockmaster.eoq, >>>>> stockmaster.volume, >>>>> stockmaster.grossweight, >>>>> stockmaster.netweight, >>>>> stockmaster.barcode, >>>>> stockmaster.discountcategory, >>>>> stockmaster.taxcatid, >>>>> stockmaster.decimalplaces, >>>>> stockmaster.nextserialno, >>>>> stockmaster.pansize, >>>>> stockmaster.shrinkfactor >>>>> FROM >>>>> stockmaster >>>>> >>>>> * INNER JOIN stockdescriptiontranslations ON >>>>> (stockmaster.stockid = stockdescriptiontranslations.**stockid)* >>>>> WHERE >>>>> stockmaster.stockid = '".$StockID."'" >>>>> ; >>>>> >>>>> if we do not want a "fall-back" to default language, the INNER JOIN >>>>> will be: >>>>> * stockdescriptiontranslations ON (stockmaster.stockid = >>>>> stockdescriptiontranslations.stockid AND '".$Language."'= >>>>> stockdescriptiontranslations.language_id)* >>>>> >>>>> Advantages: In multi-languages companies, users can have the >>>>> description in UserSettings' language. Or if they switch to customers' >>>>> language, see all the system as the customer point of view. >>>>> >>>>> * About Google Translate API: >>>>> >>>>> Yes, I agree. I prefer Google Translate as the first step, not the >>>>> last one. >>>>> >>>>> I do not trust on any automatic translator (Babylon, Systrans, Word >>>>> Magic, Google Translate, etc.). They are helpful but inaccurate and >>>>> imprecise. For one word in a language, other language has several words, >>>>> each one with accurate and precise meanings. Also, they have other >>>>> mistakes: frequently lack of agreement in gender and number (when translate >>>>> to French), frequently wrong adjective order (when translate to Spanish), >>>>> etc. Recently, we saw the effect of an automatic translation of "Pan size": >>>>> "Panoramic size" in Spanish, "Dish size" in French, "Round size" in German >>>>> (all no sense). >>>>> >>>>> Also, other reason: company "scope" may be variable. I explain myself: >>>>> + In marketing, the best is a "polished" description in the customer's >>>>> language. If you do not have it, it is better to have a "not so good" >>>>> translation than nothing ("Not available"). >>>>> + But in some countries, for legal purposes, invoices and other >>>>> documents with descriptions in languages other than country's language are >>>>> not valid. Also, in some countries, local language is "mandatory" over >>>>> other languages (if there is a mistake in automatic translation to local >>>>> language, company will be in troubles). >>>>> >>>>> I prefer to have an human-translated description and the choice >>>>> between: (1) fall back to system default language; (2) automatic >>>>> translation (Google Translate API); and (3) say "Not available". >>>>> >>>>> * About description in stockmaster >>>>> >>>>> Depending on the way we choose (coding), we can >>>>> (1) Leave stockmaster.description and stockmaster.longdescription as a >>>>> backup, in case of we concentrate descriptions. >>>>> (2) Leave stockmaster.description and stockmaster.longdescription as >>>>> is, in case of we do not concentrate descriptions. >>>>> >>>>> >>>>> (Comment): It is also the same problem if we "standardise" title, >>>>> label, id, field-name and variable-name of shortdescription and >>>>> longdescription to an information exchange standard name >>>>> (e.g. Today we have label="Part Description (short)" and fieldname=" >>>>> descriptiontranslation" (in stockdescriptiontranslations); >>>>> label="Part Description (long):" and fieldname="longdescription"). >>>>> Best regards, Rafael. >>>>> >>>>> >>>>> 2014-12-19 14:43 GMT-06:00 Phil Daintree <ph...@lo...>: >>>>> >>>>> Hi Rafael, >>>>>> >>>>>> I see what you did to stockdescriptiontranslations - adding the new >>>>>> field for longdescription and a field for last update. >>>>>> I am not sure about having the main item description also in that >>>>>> table. There are a LOT of places where we refer to stockmaster.description >>>>>> and everywhere that would need to add another query to get the description >>>>>> or the script would fail. My idea with the stockdescriptiontranslations was >>>>>> to have the description presented to customers in their language. The >>>>>> business operates in only the one adopted language. >>>>>> The google translate API sounds good - but I wonder about the >>>>>> response if we try to use it to print a long invoice where the item >>>>>> descriptions are not translated? Better I think to populate the table >>>>>> appropriately using the google translate API so that the data is available >>>>>> when we need it. Maybe when we set up the item to start with the google >>>>>> traslate API gives a first stab at the translated description if you use a >>>>>> button or something like that would then avoid empty translations from the >>>>>> beginning. >>>>>> >>>>>> We use stockmaster.description and stockmaster.longdescription I >>>>>> think it best to keep the fields in descriptiontranslation table to match. >>>>>> >>>>>> Phil >>>>>> >>>>>> Phil Daintree >>>>>> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz >>>>>> >>>>>> On 19/12/14 07:08, Rafael Chacón wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> * I agree that removing fields is risky. That is why I recommended >>>>>> add fields rather than change them. If we forget one, only one, instance >>>>>> that can cause problems. I suggestion to leave them one generation as >>>>>> backup ( (to be dropped in the version after the version with the change). >>>>>> >>>>>> * I think we can improve code speed and its readability merging ALL >>>>>> item descriptions in ONE table, instead of penalizing everybody with this >>>>>> code. I think this because: >>>>>> + One place to store description improves code in: no recall to the >>>>>> default-languge, one IF() less {the if() that is used to define which table >>>>>> to select}. >>>>>> + More simple code: only one query (instead of two): same query for >>>>>> the default language, same query for no-default language. >>>>>> >>>>>> * When no description in selected language, I am adding the option of >>>>>> to use the Google Translate API (by the way, nice job!). For manual >>>>>> purposes: >>>>>> + $text = text to trasnlate. >>>>>> + $target = target language, ISO language code of the language to >>>>>> which the text will be translated. >>>>>> Is it correct? >>>>>> >>>>>> * Database changes: >>>>>> + I leave descriptiontranslation.descriptiontranslation for >>>>>> short_description translation (now is in use for this). Probably is better >>>>>> to rename it to shortdescription for readability. (?) >>>>>> + I added the field longdescription. I used NULL for "not available"; >>>>>> reasons: saves space/transmission and use the IS NULL and IS NOT NULL >>>>>> operators. >>>>>> + I added a field for the version control of the record. >>>>>> >>>>>> Best regards, Rafael. >>>>>> >>>>>> 2014-12-18 2:26 GMT-06:00 Phil Daintree <ph...@lo...>: >>>>>>> >>>>>>> Looks like there is a bug there - I thought I was only creating a >>>>>>> record where there was a non-empty translation - I am committing what I >>>>>>> think will fix it now. >>>>>>> What a cool idea with google translate!! Great stuff :-) >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> Phil Daintree >>>>>>> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz >>>>>>> >>>>>>> On 18/12/14 13:35, Pak Ricard wrote: >>>>>>> >>>>>>> Hi: >>>>>>> >>>>>>> I think we are OK with existing table and adding some fields will >>>>>>> be OK, but there are some issues I would like to point out, >>>>>>> >>>>>>> Why, on items without traslation, do we keep a row in that table? >>>>>>> Why do we have rows without any useful information? I think it makes SQL >>>>>>> queries more complicated, and I can't see the advantage of this. Please >>>>>>> check capture01 attached file from phpMyAdmin. For all items without >>>>>>> translation, there's a row with stockid, and "Array" as language_id, and no >>>>>>> descriptiontranslation. No clue why. Is it a bug or serves some needs I >>>>>>> can't see? >>>>>>> >>>>>>> I agree with Phil that the long description addition should be a >>>>>>> "copy - paste" of the short description one. At first glance should not be >>>>>>> difficult. That's why I supposed it was already coded or not coded for some >>>>>>> reason. >>>>>>> >>>>>>> I think we should add a field called revisionneeded set to TRUE >>>>>>> when description or long description have been modified or FALSE otherwise. >>>>>>> Then, some script to list the items needing revision of translation. >>>>>>> Usually the person translating is not the same as the person in charge of >>>>>>> maintaining the item info in original language. >>>>>>> >>>>>>> I am working with automatic translation API from Google >>>>>>> https://console.developers.google.com. It's a Google paid service, >>>>>>> and I think it's worth it (20 USD for 1.000.000 characters translated), as >>>>>>> it does the rough job and humans only need to revise and correct here and >>>>>>> there. >>>>>>> >>>>>>> First tests have been succesful, so once we have this table stockdescriptiontranslations >>>>>>> up and running OK I will commit some scripts, mainly: >>>>>>> script automatically translating the descriptions without >>>>>>> translation or recently modified. >>>>>>> script to show automatic translations needing human supervision >>>>>>> (probably the same or a mod of the script mentioned in previous paragraph) >>>>>>> >>>>>>> Specially to Rafael: I add / modify fields quite often, and never >>>>>>> had an issue, except when I shortened a text field :-( . Do a table backup >>>>>>> just before start messing around, just in case. >>>>>>> >>>>>>> Hope it helps and we all find a clear way to move forward on this. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Ricard >>>>>>> >>>>>>> 2014-12-18 6:47 GMT+08:00 Rafael Chacón < >>>>>>> raf...@gm...>: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> My arguments: >>>>>>>> >>>>>>>> * About tables: IMHO (but I am not a PHP programmer), >>>>>>>> >>>>>>>> CREATE TABLE IF NOT EXISTS `stockdescriptiontranslations` ( >>>>>>>> `stockid` varchar(20) NOT NULL DEFAULT '', >>>>>>>> `language_id` varchar(10) NOT NULL DEFAULT 'en_GB.utf8', >>>>>>>> `descriptiontranslation` varchar(50) NOT NULL, >>>>>>>> PRIMARY KEY (`stockid`,`language_id`) >>>>>>>> ) ENGINE=InnoDB DEFAULT CHARSET=utf8; >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> CREATE TABLE IF NOT EXISTS `stockdescription` ( >>>>>>>> `stockid` varchar(20) NOT NULL DEFAULT '' COMMENT 'Item code', >>>>>>>> `language` varchar(10) NOT NULL DEFAULT '' COMMENT 'Item language >>>>>>>> code', >>>>>>>> `short` varchar(50) DEFAULT NULL COMMENT 'Item short description', >>>>>>>> `long` text COMMENT 'Item long description', >>>>>>>> PRIMARY KEY (`stockid`,`language`) >>>>>>>> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Item descriptions'; >>>>>>>> >>>>>>>> look very similar. I suppose it will be easy to "update" the first >>>>>>>> table: add new fields, modify others (I have the code to create the second >>>>>>>> table, but not to update de first table). >>>>>>>> >>>>>>>> * About "hot plug-in": I am not sure if that is a common need, but >>>>>>>> I am worry that if we modify fields instead of adding fields --if there is >>>>>>>> any error or oversight-- we could affect the company operation. My >>>>>>>> suggestion is to add fields of the second table inside de first table (if >>>>>>>> use old table). >>>>>>>> >>>>>>>> * About compatibility with CARTwebERP: Months before Mo.Kelly dead, >>>>>>>> we were working on this. I do not know how widespread is this. I saw the >>>>>>>> code in Joomla! Extensions Directory (http://extensions.joomla.org). >>>>>>>> It has my translation to Spanish and to French, but I can not see anything >>>>>>>> related with additional tables. >>>>>>>> >>>>>>>> * About speed and readability of the code: I prefer the argument >>>>>>>> of someone who knows better this topic. >>>>>>>> >>>>>>>> Best regards, Rafael. >>>>>>>> >>>>>>>> >>>>>>>> 2014-12-17 15:39 GMT-06:00 <ph...@lo...>: >>>>>>>> >>>>>>>>> I wasn't thinking it would be that difficult... we don't need a new >>>>>>>>> table do we? >>>>>>>>> Why can't we use the existing table and just add a field for the >>>>>>>>> translated long description ... applying similar logic for the >>>>>>>>> translation was we do for the short description? >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> On 2014-12-17 13:58, Rafael Chacón wrote: >>>>>>>>> > Hi Ricard, >>>>>>>>> > >>>>>>>>> > I will be glad to commit changes for short and long description >>>>>>>>> > translation. but I need help from PHP programmers. I explain >>>>>>>>> myself: >>>>>>>>> > >>>>>>>>> > * We use a new table (not an exist table): >>>>>>>>> > CREATE TABLE IF NOT EXISTS `stockdescription` ( >>>>>>>>> > `stockid` varchar(20) NOT NULL DEFAULT '' COMMENT 'Item code', >>>>>>>>> > `language` varchar(10) NOT NULL DEFAULT '' COMMENT 'Item >>>>>>>>> language >>>>>>>>> > code', >>>>>>>>> > `short` varchar(50) DEFAULT NULL COMMENT 'Item short >>>>>>>>> description', >>>>>>>>> > `long` text COMMENT 'Item long description', >>>>>>>>> > PRIMARY KEY (`stockid`,`language`) >>>>>>>>> > ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Item >>>>>>>>> descriptions'; >>>>>>>>> > >>>>>>>>> > This is for: (1) "Hot add" to a working copy of webERP and >>>>>>>>> "secure >>>>>>>>> > backup" of old operation; (2) compatibility with a Joomla >>>>>>>>> extension >>>>>>>>> > e-Cart;"Minor" speed and readability (?). >>>>>>>>> > >>>>>>>>> > --> To commit changes, Do we use a new table or modify an >>>>>>>>> existing >>>>>>>>> > one? >>>>>>>>> > >>>>>>>>> > * We have to modify several scripts (e.g. Stocks.php, >>>>>>>>> > PrintCustTrans.php, PrintCustTransportrait.php, etc.). When >>>>>>>>> there is >>>>>>>>> > no description in the selected language, he have two code >>>>>>>>> branches: >>>>>>>>> > >>>>>>>>> > (1) "Fall back" to system language (defined in ~/config.php, >>>>>>>>> > $DefaultLanguage = 'xx_XX.utf8';). If is null or empty, _('Not >>>>>>>>> > available'). Useful when we forgot to setup a translation; but >>>>>>>>> > customer sees a description in other language. >>>>>>>>> > >>>>>>>>> > (2) Directly sets to _('Not available'). A little bit faster, >>>>>>>>> but no >>>>>>>>> > information is shown to the customer (only "not available"). >>>>>>>>> > >>>>>>>>> > --> To commit changes, Do we use code with or without the "fall >>>>>>>>> back" >>>>>>>>> > to system language? >>>>>>>>> > >>>>>>>>> > * Input window for long description translation. >>>>>>>>> > It is recommended to have "side-by-side" long description >>>>>>>>> > translations, but in this case it is a big and uncomfortable >>>>>>>>> window. >>>>>>>>> > >>>>>>>>> > --> Ideas? Suggestions? >>>>>>>>> > >>>>>>>>> > Best regards, Rafael. >>>>>>>>> > >>>>>>>>> > Hi Rafael: >>>>>>>>> > >>>>>>>>> > i'm also needing the short and long description to use on the >>>>>>>>> shop >>>>>>>>> > online. It would be great if you could commit (or send via >>>>>>>>> email) the >>>>>>>>> > work done to maintain the translations of long descriptions in >>>>>>>>> webERP. >>>>>>>>> > I could help finish it :-) >>>>>>>>> > >>>>>>>>> > Regards, >>>>>>>>> > Ricard >>>>>>>>> > >>>>>>>>> > 2014-12-17 14:00 GMT+08:00 Rafael Chacón >>>>>>>>> > <raf...@gm...>: >>>>>>>>> > >>>>>>>>> >> Hi, >>>>>>>>> >> >>>>>>>>> >> I am working with stockdescription table for translation of >>>>>>>>> short >>>>>>>>> >> and long description to use in a e-cart. It is not fully tested >>>>>>>>> and >>>>>>>>> >> the main problem is the usability (easy to maintain the >>>>>>>>> >> translations). >>>>>>>>> >> Also, the field unit of mesure needs translation, except for >>>>>>>>> unit >>>>>>>>> >> of mesure symbols (m, m2, L, kg, ...). >>>>>>>>> >> >>>>>>>>> >> Best regards, Rafael. >>>>>>>>> >> El 16/12/2014 23:02, "Phil Daintree" <ph...@lo...> >>>>>>>>> >> escribió: >>>>>>>>> >> >>>>>>>>> >> I have not coded that, but no reason why we couldn't add a text >>>>>>>>> >> field to stockdescriptiontranslations for >>>>>>>>> longdescriptiontranslation >>>>>>>>> >> and add in a field to the stock form to allow the field to be >>>>>>>>> >> translated to the maintained language(s) >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>>>>>> from Actuate! Instantly Supercharge Your Business Reports and >>>>>>>>> Dashboards >>>>>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration >>>>>>>>> & more >>>>>>>>> Get technology previously reserved for billion-dollar >>>>>>>>> corporations, FREE >>>>>>>>> >>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>>>>>>> _______________________________________________ >>>>>>>>> Web-erp-developers mailing list >>>>>>>>> Web...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>>>>> from Actuate! Instantly Supercharge Your Business Reports and >>>>>>>> Dashboards >>>>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration >>>>>>>> & more >>>>>>>> Get technology previously reserved for billion-dollar corporations, >>>>>>>> FREE >>>>>>>> >>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>>>>>> _______________________________________________ >>>>>>>> Web-erp-developers mailing list >>>>>>>> Web...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>>>>>> Get technology previously reserved for billion-dollar corporations, FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>>>> from Actuate! Instantly Supercharge Your Business Reports and >>>>>>> Dashboards >>>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & >>>>>>> more >>>>>>> Get technology previously reserved for billion-dollar corporations, >>>>>>> FREE >>>>>>> >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Web-erp-developers mailing list >>>>>>> Web...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>>>>> Get technology previously reserved for billion-dollar corporations, FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>>> from Actuate! Instantly Supercharge Your Business Reports and >>>>>> Dashboards >>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & >>>>>> more >>>>>> Get technology previously reserved for billion-dollar corporations, >>>>>> FREE >>>>>> >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>> >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>>> from Actuate! Instantly Supercharge Your Business Reports and >>>>> Dashboards >>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & >>>>> more >>>>> Get technology previously reserved for billion-dollar corporations, >>>>> FREE >>>>> >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>>> with Interactivity, Sharing, Native Excel Exports, App Integration & >>>> more >>>> Get technology previously reserved for billion-dollar corporations, FREE >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Dive into the World of Parallel Programming! The Go Parallel Website, >>> sponsored by Intel and developed in partnership with Slashdot Media, is >>> your >>> hub for all things parallel software development, from weekly thought >>> leadership blogs to news, videos, case studies, tutorials and more. Take >>> a >>> look and join the conversation now. http://goparallel.sourceforge.net >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> > |
