web-erp-developers — Discussion on development of webERP

Re: [WebERP-developers] Float accuracy problem

[ExsonQu <hex...@gm...>]

*Hi, all,*

        I post Tim's reply as following:

        Best regards!

        Exson

         
Tim wrote
>           Hi Robert, as I said to Exson in the off list conversations
> integer is
> the only really reliable way to go with this and is what all
> commercial accounting systems do. *But* it is a huge task to change
> what is a design decision that affects every script and most of the
> database tables.
> 
> -Tim

        



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657952.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] How to keep the part_pics folder outside weberp structure folders

[gilberto d. s. a. <gs...@gm...>]

Hi.

You could use clause alias for your httpd server (apache2.4) current
release. please see [1].

If  your server is shared host like (hostgator, dreamhost, etc) you could
use .htaccess with directives (alias, directory, etc) inside your
product-image-for-every-cia and point these links to unique-dir-with-images
of your http server.

Please see too on apache 2.2 (old stable release) examples [2].

[1] http://httpd.apache.org/docs/current/mod/mod_alias.html
[2] http://httpd.apache.org/docs/2.2/mod/mod_alias.html

2015-01-06 6:16 GMT-02:00 Pak Ricard <pak...@gm...>:

> Hi all:
>
> We would like to keep all images stored in part_pics folder in another
> folder outside the webERP structure.
> Example: Instead of using
> www.my_company.com/weberp/companies/company_name/part_pics
> I would like to use www.my_other_domain.com/images/part_pics
>
> I tried to change part_pics in config table, in many ways but failed to
> get outside www.my_company.com
>
> is there any way to achieve this, or I must to keep the pictures inside
> the folder structure of webERP?
>
> Regards,
> Ricard
>
>
> ------------------------------------------------------------------------------
> 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
>
>


-- 
gilberto dos santos alves
+55(11)9-8646-5049
sao paulo - sp - brasil

Re: [WebERP-developers] Float accuracy problem

[rfthomas <rf...@as...>]

This is an old problem that is on all computer systems and actually predates
computer systems.  Floating point does not solve the problem, rather it will
make it worse.  Our company works with floating point calculations in
engineering and manufacturing.  Loss of precision is a major problem.  There
are numerous references explaining this problem in detail:

Numerical Mathematical Analysis - Scarborough
Computerized Accounting Methods and Controls - Tyran
Error Propagation for DIfference Methods - Henrici

Cobol and other accounting oriented languages normally utilize integers in
fixed formats to store numbers.

Order of operations, rounding and truncation all create specific problems. 
For example:

if the cost of an item is 3 for $1.00, then if one buys one the price is
$0.3333... Assuming that this unit price is stored to 2 places, i.e. $0.33
if a customer buys 3 pieces then the cost to the customer is $0.99 and the
business must absorb the $0.01 shortage.

There are no clean solutions.  One must use finite values and live with
results.  If rounding of the unit prices is performed then a consistent
policy needs to be established.

Floating point numbers should not be used since by their nature certain
values are difficult to store.  It is normal to see a value of 1. stored as
.9999999 if using Real*4 or .999999999999999 if using Real*8.

Storage is cheap and readily expanded.  Computers are very fast and the
numerical calculations simple.  We would prefer to expand fields and use
character or integer representations for all numbers.



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657949.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] Float accuracy problem

[Rafael C. <raf...@gm...>]

Hi Exson,

Yes, I think an "accounting adjustment for differences in calculus" is a
bad image for webERP's precision.

A couple of suggestions:

1. In calculations, to have "precedence" in calculus. I mean: first
additions over subtractions; first multiplication over divisions.
Subtractions and divisions destroy precision (reduce the quantity of
"significant digits").

2. If extra decimals in fixed decimal do not solve the problem, try with
the floating (9e99) with +1 the quantity of digits of the bigger number to
be shown. ref: http://dev.mysql.com/doc/refman/5.0/en/fixed-point-types.html

Best regards, Rafael.

2015-01-06 9:11 GMT-06:00 ExsonQu <hex...@gm...>:

> *Hi, Rafael and Richard,*
>
>            Thank you for your feedback.
>
>           And I've also attached Tim's feedback about the cause of this
> problem. As Tim point out, we may use webERP's current
> locale_number_format() function to solve this problem.
>           I believe the effort is deserved since webERP is accounting
> application.
>           If no objection, I'd like to initiate a schedule to solve this
> problem.
>
>           Thanks again for the feedback from all of you!
>
>           Best regards!
>
>           Exson
>
>
>
> Tim wrote
> >           The problem is a general one with the way computers deal with
> > floating
> > points. Mysql stores floating point values in a 32 bit value, using an
> > algorithm to convert the floating point number to a 32 bit integer,
> > and then reversing it to get back to a floating point number. This
> > means that it is only actually capable of storing 4,294,967,295
> > different floating point numbers. However in reality there is an
> > infinite number of them, even just between 0 and 1 there is an
> > infinite number. This inevitably means that there are an infinite
> > number of floating point numbers that when converted to a 32 bit int,
> > and then back again do not end up with the initial value. To see an
> > example of this enter the following sql into a mysql terminal:
> >
> > SELECT 3.1415E0 + 0.9585E0 - 4.1E0;
> >
> > the E0 just forces mysql to think of these numbers as floats. The above
> > gives
> >
> > +-----------------------------+
> > | 3.1415E0 + 0.9585E0 - 4.1E0 |
> > +-----------------------------+
> > |       8.881784197001252e-16 |
> > +-----------------------------+
> >
> > on my Debian system but may give alternatives on your operating systems.
> >
> > Commercial accounting systems store all numbers as integers with a
> > number of decimal places and just convert back to floats when
> > displaying them.
> >
> > Hope this helps,
> > Tim
> >
> > Well imagine a stock item XYZ that has the decimalplaces field set to
> > 4. The quantity field in the locstock table should be of type integer.
> > If we have a quantity of 57.561 of XYZ in a particular location then
> > the quantity field in the locstock table would be 575610. To display
> > the quantity on the screen you convert it into the correct format so
> > here it is 575610/pow(10, 4). This could probably be done via the
> > number_format functions. We already hold the decimal places number for
> > stock items and monetary amounts.
> >
> > This "bug" has long been a problem in openerp as well. I know its been
> > discussed on that project over and over for many years, but I am not
> > sure whether they have taken any action yet. It would be a big plus to
> > change it, but a _lot_ of work.
> >
> > Tim
>
>
> Pak Ricard wrote
> > Hi Exson:
> >
> > YES! We find some tiny differences but after time they become noticeable
> > (still small, but there's a bug somewhere with float).
> > We detected it also in multicurrency calcualtions, so I guess it is due
> to
> > diffrerent ways to do the same calculations in different parts of webERP,
> > and the float precission tricks us here.
> >  I will take more attention and try to track it down.
> >
> > Regards,
> > Ricard
> >
> > 2015-01-05 13:01 GMT+08:00 ExsonQu &lt;
>
> > hexinfans@
>
> > &gt;:
> >
> >> *Dear all,*
> >>
> >>      I've received one more case about this. The number in the inventory
> >> account does not match with the inventory actual value. There is always
> >> some
> >> variance even we set up more decimal places.
> >>
> >>      Does anybody meet this same problem?
> >>
> >>      Best regards!
> >>
> >>      Exson
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657939.html
> >> Sent from the web-ERP-developers mailing list archive at Nabble.com.
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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-erp-developers@.sourceforge
>
> >> 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-erp-developers@.sourceforge
>
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657944.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [WebERP-developers] Float accuracy problem

[ExsonQu <hex...@gm...>]

*Hi, Rafael and Richard,*

           Thank you for your feedback. 

          And I've also attached Tim's feedback about the cause of this
problem. As Tim point out, we may use webERP's current
locale_number_format() function to solve this problem. 
          I believe the effort is deserved since webERP is accounting
application. 
          If no objection, I'd like to initiate a schedule to solve this
problem. 

          Thanks again for the feedback from all of you!
        
          Best regards!

          Exson
         


Tim wrote
>           The problem is a general one with the way computers deal with
> floating
> points. Mysql stores floating point values in a 32 bit value, using an
> algorithm to convert the floating point number to a 32 bit integer,
> and then reversing it to get back to a floating point number. This
> means that it is only actually capable of storing 4,294,967,295
> different floating point numbers. However in reality there is an
> infinite number of them, even just between 0 and 1 there is an
> infinite number. This inevitably means that there are an infinite
> number of floating point numbers that when converted to a 32 bit int,
> and then back again do not end up with the initial value. To see an
> example of this enter the following sql into a mysql terminal:
> 
> SELECT 3.1415E0 + 0.9585E0 - 4.1E0;
> 
> the E0 just forces mysql to think of these numbers as floats. The above
> gives
> 
> +-----------------------------+
> | 3.1415E0 + 0.9585E0 - 4.1E0 |
> +-----------------------------+
> |       8.881784197001252e-16 |
> +-----------------------------+
> 
> on my Debian system but may give alternatives on your operating systems.
> 
> Commercial accounting systems store all numbers as integers with a
> number of decimal places and just convert back to floats when
> displaying them.
> 
> Hope this helps,
> Tim
> 
> Well imagine a stock item XYZ that has the decimalplaces field set to
> 4. The quantity field in the locstock table should be of type integer.
> If we have a quantity of 57.561 of XYZ in a particular location then
> the quantity field in the locstock table would be 575610. To display
> the quantity on the screen you convert it into the correct format so
> here it is 575610/pow(10, 4). This could probably be done via the
> number_format functions. We already hold the decimal places number for
> stock items and monetary amounts.
> 
> This "bug" has long been a problem in openerp as well. I know its been
> discussed on that project over and over for many years, but I am not
> sure whether they have taken any action yet. It would be a big plus to
> change it, but a _lot_ of work.
> 
> Tim


Pak Ricard wrote
> Hi Exson:
> 
> YES! We find some tiny differences but after time they become noticeable
> (still small, but there's a bug somewhere with float).
> We detected it also in multicurrency calcualtions, so I guess it is due to
> diffrerent ways to do the same calculations in different parts of webERP,
> and the float precission tricks us here.
>  I will take more attention and try to track it down.
> 
> Regards,
> Ricard
> 
> 2015-01-05 13:01 GMT+08:00 ExsonQu <

> hexinfans@

> >:
> 
>> *Dear all,*
>>
>>      I've received one more case about this. The number in the inventory
>> account does not match with the inventory actual value. There is always
>> some
>> variance even we set up more decimal places.
>>
>>      Does anybody meet this same problem?
>>
>>      Best regards!
>>
>>      Exson
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657939.html
>> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> 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-erp-developers@.sourceforge

>> 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-erp-developers@.sourceforge

> https://lists.sourceforge.net/lists/listinfo/web-erp-developers





--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657944.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

[WebERP-developers] How to keep the part_pics folder outside weberp structure folders

[Pak R. <pak...@gm...>]

Hi all:

We would like to keep all images stored in part_pics folder in another
folder outside the webERP structure.
Example: Instead of using
www.my_company.com/weberp/companies/company_name/part_pics
I would like to use www.my_other_domain.com/images/part_pics

I tried to change part_pics in config table, in many ways but failed to get
outside www.my_company.com

is there any way to achieve this, or I must to keep the pictures inside the
folder structure of webERP?

Regards,
Ricard

Re: [WebERP-developers] Float accuracy problem

[Pak R. <pak...@gm...>]

Hi Exson:

YES! We find some tiny differences but after time they become noticeable
(still small, but there's a bug somewhere with float).
We detected it also in multicurrency calcualtions, so I guess it is due to
diffrerent ways to do the same calculations in different parts of webERP,
and the float precission tricks us here.
 I will take more attention and try to track it down.

Regards,
Ricard

2015-01-05 13:01 GMT+08:00 ExsonQu <hex...@gm...>:

> *Dear all,*
>
>      I've received one more case about this. The number in the inventory
> account does not match with the inventory actual value. There is always
> some
> variance even we set up more decimal places.
>
>      Does anybody meet this same problem?
>
>      Best regards!
>
>      Exson
>
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657939.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [WebERP-developers] Float accuracy problem

[Rafael C. <raf...@gm...>]

Hi Exson,

In inventory I do not have this problem, but in currency I have it.

Exchange rate has few room (decimals) to allocate enough "significant
digits" (sorry I do not know the exact translation). I explain myselt: 600
CRC =1 USD, that is a exchange rate of 0.0016 USD/CRC. The result: For a
transaction of 111.111,11 (8 "significant digits") we need 3+8= 11 decimals
in the exchange rate. The real solution is to use "scientific notation"
with  enough "significant digits". I did not the best (but fast): I
modified to have 14 decimals.

Best regards, Rafael.

2015-01-04 23:01 GMT-06:00 ExsonQu <hex...@gm...>:

> *Dear all,*
>
>      I've received one more case about this. The number in the inventory
> account does not match with the inventory actual value. There is always
> some
> variance even we set up more decimal places.
>
>      Does anybody meet this same problem?
>
>      Best regards!
>
>      Exson
>
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657939.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [WebERP-developers] Float accuracy problem

[ExsonQu <hex...@gm...>]

*Dear all,*

     I've received one more case about this. The number in the inventory
account does not match with the inventory actual value. There is always some
variance even we set up more decimal places.

     Does anybody meet this same problem?

     Best regards!

     Exson
     



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657939.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] Default language and default theme

[Rafael C. <raf...@gm...>]

HI Phil,

Thank you very much.

Best regards, Rafael.

2014-12-31 15:26 GMT-06:00 Phil Daintree <ph...@lo...>:

>  Yes - these are the defaults before login... once logged in they are
> retrieved from the DB from the user's record.
>
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz
>
> On 01/01/15 05:00, Rafael Chacón wrote:
>
>   Hi, happy new year to all!,
>
> Two questions:
>
> 1. Is there any reason to store (hard code) default language in
> configuration.php instead of database table "config" ?
>
> 2. Is there any reason to store (hard code) default theme in sesion.inc
> instead of database table "config" ?
>
> As default, I mean for login screen and as first option in www_users.php.
>
> Best regards, Rafael.
>
>
> ------------------------------------------------------------------------------
> 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 lis...@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
>
>

Re: [WebERP-developers] Default language and default theme

[Phil D. <ph...@lo...>]

Yes - these are the defaults before login... once logged in they are 
retrieved from the DB from the user's record.

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 01/01/15 05:00, Rafael Chacón wrote:
>
>  Hi, happy new year to all!,
>
> Two questions:
>
> 1. Is there any reason to store (hard code) default language in 
> configuration.php instead of database table "config" ?
>
> 2. Is there any reason to store (hard code) default theme in 
> sesion.inc instead of database table "config" ?
>
> As default, I mean for login screen and as first option in www_users.php.
>
> Best regards, Rafael.
>
>
>
> ------------------------------------------------------------------------------
> 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

[WebERP-developers] Default language and default theme

[Rafael C. <raf...@gm...>]

Hi, happy new year to all!,

Two questions:

1. Is there any reason to store (hard code) default language in
configuration.php instead of database table "config" ?

2. Is there any reason to store (hard code) default theme in sesion.inc
instead of database table "config" ?

As default, I mean for login screen and as first option in www_users.php.

Best regards, Rafael.

Re: [WebERP-developers] long description translation

[Rafael C. <raf...@gm...>]

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

[WebERP-developers] Reverse GRNS serial

[RL <rl...@ya...>]

Hello you guys, I'm trying to reverse a controlled item, but I just can´t, this is the issue:
1) I create an item, les say controlled01 as a controlled, not serial.2) I made a PO and received 40 of these controlled01, at this moment I have in my stock, 40 with serialno='BBD0344'3) I invoice 30 of those 40, at this moment I have 10 in my stock4) I want to return 4 to my vendor because I just realized that they were broken, so I create a Debit Note5) I try to Reverse an Outstanding GRN and that is where I get this error message:ERROR Message Report : Unfortunately, of the original number (40) that were received on serial number BBD0344 only 10 remain. The GRN can only be reversed if all the original serial number items are still in stock in the location they were received into

But I already sold those 30.
Code of ReverseGRN.php
while ($SerialStockMoves = DB_fetch_array($GetStockMoveResult)){
Line 93 to 109            $SQL = "SELECT stockserialitems.quantity
                    FROM stockserialitems
                    WHERE stockserialitems.stockid='" . $GRN['itemcode'] . "'
                    AND stockserialitems.loccode ='" . $GRN['intostocklocation'] . "'
                    AND stockserialitems.serialno ='" . $SerialStockMoves['serialno'] . "'";
            $GetQOHResult = DB_query($SQL,_('Unable to retrieve the quantity on hand of') . ' ' . $GRN['itemcode'] . ' ' . _('for Serial No') . ' ' . $SerialStockMoves['serialno']);
            $GetQOH = DB_fetch_row($GetQOHResult);
            if ($GetQOH[0] < $SerialStockMoves['moveqty']){
                /*Then some of the original goods received must have been sold
                or transfered so cannot reverse the GRN */
                prnMsg(_('Unfortunately, of the original number') . ' (' . $SerialStockMoves['moveqty'] . ') ' . _('that were received on serial number') . ' ' . $SerialStockMoves['serialno'] . ' ' . _('only') . ' ' . $GetQOH[0] . ' ' . _('remain') . '. ' . _('The GRN can only be reversed if all the original serial number items are still in stock in the location they were received into'),'error');
                include ('includes/footer.inc');
                exit;
            }
        }

What is this condition for if ($GetQOH[0] < $SerialStockMoves['moveqty']){ ??
 What changes should be made in order to return those 4?Is there something else to take into consideration?


Thanks a lot




   

Re: [WebERP-developers] long description translation

[Pak R. <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
>
>

Re: [WebERP-developers] long description translation

[Rafael C. <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
>
>

Re: [WebERP-developers] long description translation

[Pak R. <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
>
>

Re: [WebERP-developers] long description translation

[Rafael C. <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
>
>

Re: [WebERP-developers] long description translation

[Phil D. <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 567890
http://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... 
> <mailto: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 567890
>     http://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...
>>     <mailto: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...
>>         <mailto: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...
>>             <mailto: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... <mailto: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...
>>             <mailto: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...
>>         <mailto: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...  <mailto: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...
>     <mailto: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

Re: [WebERP-developers] long description translation

[Rafael C. <raf...@gm...>]

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

Re: [WebERP-developers] long description translation

[Phil D. <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 567890
http://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... <mailto: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...
>     <mailto: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...
>         <mailto: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...
>         <mailto: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...
>         <mailto: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...
>     <mailto: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

Re: [WebERP-developers] long description translation

[Pak R. <pak...@gm...>]

Hi Rafael:

Sound OK, but "The fields stockmaster.description and
stockmaster.longdescription became obsolete (to be dropped in the future)"
seems pretty risky and bulky. There are zillions of instances of
stockmaster.description and stockmaster.longdescription in webERP. I see it
a major revision of almost all webERP.

Also, many installations do only use 1 language, and we'll penalizing
everybody with this extra code.

What if stockmaster.description and stockmaster.longdescription are left
"as is" and we keep translations only in stockdescriptiontranslations, as
suggested by Phil? Almost all code is reusable, we only need to add the
missing code for longdescription.

Just my 2c


Regards,
Ricard

2014-12-18 11:52 GMT+08:00 Rafael Chacón <raf...@gm...>:
>
> Hi,
>
> * About existing table: If no additional comments on this topic, I will do
> the sql file to modify `stockdescriptiontranslations`.
>
> * Info in rows:
> My proposal is to merge ALL item descriptions in ONE table (all short
> description -item title- and all long description -item narrative-; all
> languages including system default language). The fields
> stockmaster.description and stockmaster.longdescription became obsolete (to
> be dropped in the future). Short and Long descriptions of a specific
> language are on the same record. This simplifies the query code.
> In this case:
> 1. If no short_description and no long_description translation for an
> item, it is unneeded to have this record.
> 2. If short_description and/or long_description translation are null
> (empty), we can do or not an additional query to get the missing
> description in the default language. That is that I called "Fall back to
> system language" in previous message.
>
> Parameters:
> $stockid = '2000000300047';// As example. Defined elsewhere...
> $Language = 'en_US.utf8';// As example. Defined elsewhere...
> $DefaultLanguage = 'es_ES.utf8';// As example. Defined elsewhere...
>
> My code is:
> $ShortDescription = _('Not available');// In case of no description.
> $LongDescription = _('Not available');// In case of no description.
>
> $Query="SELECT * FROM stockdescription WHERE stockid='" . $stockid ."' AND
> language='" . $Language . "'";
> $Result=mysqli_query($Connection, $Query);
> $Row=mysqli_fetch_array($Result);
>
> if(!empty($Row['short'])) {// If not empty, sets the description in the
> selected language.
>     $ShortDescription = htmlspecialchars($Row['short']);
> // BEGIN: Fall back to the default language.
> } else {
>     $Query="SELECT * FROM stockdescription WHERE stockid='" . $stockid ."'
> AND language='" . $DefaultLanguage . "'";
>     $Result=mysqli_query($Connection, $Query);
>     $Row=mysqli_fetch_array($Result);
>     if(!empty($Row['short'])) {// If not empty, sets the description in
> the default language.
>         $ShortDescription = htmlspecialchars($Row['short']);
>     }
> // END: Fall back to the default language.
> }
>
> if(!empty($Row['long'])) {// If not empty, sets the description in the
> selected language.
>     $LongDescription = nl2br(htmlspecialchars($Row['long']));
> // BEGIN: Fall back to the default language.
> } else {
>     $Query="SELECT * FROM stockdescription WHERE stockid='" . $stockid ."'
> AND language='" . $DefaultLanguage . "'";
>     $Result=mysqli_query($Connection, $Query);
>     $Row=mysqli_fetch_array($Result);
>     if(!empty($Row['long'])) {// If not empty, sets the description in the
> default language.
>         $LongDescription = nl2br(htmlspecialchars($Row['long']));
>     }
> // END: Fall back to the default language.
> }
>
> Instead of the "fall back code", it could be also the Google Translate
> API. Also, it can be deleted the fall back code (between comments "BEGIN"
> and "END").
>
>
>
> Note: I enclose a PrintScreen of my stockdescriptiontranslations table. It
> is only plain text, no arrays.
>
> Best regards, Rafael.
>
> 2014-12-17 18:35 GMT-06:00 Pak Ricard <pak...@gm...>:
>
>> 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, 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
>
>

Re: [WebERP-developers] long description translation

[Rafael C. <raf...@gm...>]

Hi,

* About existing table: If no additional comments on this topic, I will do
the sql file to modify `stockdescriptiontranslations`.

* Info in rows:
My proposal is to merge ALL item descriptions in ONE table (all short
description -item title- and all long description -item narrative-; all
languages including system default language). The fields
stockmaster.description and stockmaster.longdescription became obsolete (to
be dropped in the future). Short and Long descriptions of a specific
language are on the same record. This simplifies the query code.
In this case:
1. If no short_description and no long_description translation for an item,
it is unneeded to have this record.
2. If short_description and/or long_description translation are null
(empty), we can do or not an additional query to get the missing
description in the default language. That is that I called "Fall back to
system language" in previous message.

Parameters:
$stockid = '2000000300047';// As example. Defined elsewhere...
$Language = 'en_US.utf8';// As example. Defined elsewhere...
$DefaultLanguage = 'es_ES.utf8';// As example. Defined elsewhere...

My code is:
$ShortDescription = _('Not available');// In case of no description.
$LongDescription = _('Not available');// In case of no description.

$Query="SELECT * FROM stockdescription WHERE stockid='" . $stockid ."' AND
language='" . $Language . "'";
$Result=mysqli_query($Connection, $Query);
$Row=mysqli_fetch_array($Result);

if(!empty($Row['short'])) {// If not empty, sets the description in the
selected language.
    $ShortDescription = htmlspecialchars($Row['short']);
// BEGIN: Fall back to the default language.
} else {
    $Query="SELECT * FROM stockdescription WHERE stockid='" . $stockid ."'
AND language='" . $DefaultLanguage . "'";
    $Result=mysqli_query($Connection, $Query);
    $Row=mysqli_fetch_array($Result);
    if(!empty($Row['short'])) {// If not empty, sets the description in the
default language.
        $ShortDescription = htmlspecialchars($Row['short']);
    }
// END: Fall back to the default language.
}

if(!empty($Row['long'])) {// If not empty, sets the description in the
selected language.
    $LongDescription = nl2br(htmlspecialchars($Row['long']));
// BEGIN: Fall back to the default language.
} else {
    $Query="SELECT * FROM stockdescription WHERE stockid='" . $stockid ."'
AND language='" . $DefaultLanguage . "'";
    $Result=mysqli_query($Connection, $Query);
    $Row=mysqli_fetch_array($Result);
    if(!empty($Row['long'])) {// If not empty, sets the description in the
default language.
        $LongDescription = nl2br(htmlspecialchars($Row['long']));
    }
// END: Fall back to the default language.
}

Instead of the "fall back code", it could be also the Google Translate API.
Also, it can be deleted the fall back code (between comments "BEGIN" and
"END").



Note: I enclose a PrintScreen of my stockdescriptiontranslations table. It
is only plain text, no arrays.

Best regards, Rafael.

2014-12-17 18:35 GMT-06:00 Pak Ricard <pak...@gm...>:
>
> 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, 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
>
>

Re: [WebERP-developers] long description translation

[Pak R. <pak...@gm...>]

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

Re: [WebERP-developers] long description translation

[Rafael C. <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
>