web-erp-developers — Discussion on development of webERP

Re: [Web-erp-developers] Interface

[Daintrees <p.d...@pa...>]

Its still wrapping - its not a huge deal.

Phil
  ----- Original Message -----=20
  From: skaill=20
  To: web...@li...=20
  Sent: Tuesday, August 03, 2004 9:09 AM
  Subject: Re: [Web-erp-developers] Interface


  Ok, I think the 800x600 should not have Inquiries and Reports wrapping =
underneath the image now which should look better.  At the same time I =
made all the headings look better in positioning.

  Please take another look here http://weberp.gocom.ca to confirm when =
you get a chance.

  Steve
    ----- Original Message -----=20
    From: Daintrees=20
    To: web...@li...=20
    Sent: Monday, August 02, 2004 4:09 PM
    Subject: Re: [Web-erp-developers] Interface


    Looks better on a 1024x768 than on a 600x800 screen. The inquiries =
and reports heading has to wrap onto two lines.

    The spaced links are less intimidating block of text too.

    Great!


    Notice that the heading/title of the page is missing?

    Phil
      ----- Original Message -----=20
      From: skaill=20
      To: web...@li...=20
      Sent: Tuesday, August 03, 2004 4:40 AM
      Subject: Re: [Web-erp-developers] Interface


      Refined some more at http://weberp.gocom.ca including spacing out =
the action links.

      Steve
        ----- Original Message -----=20
        From: Daintrees=20
        To: web...@li...=20
        Sent: Sunday, August 01, 2004 9:08 PM
        Subject: Re: [Web-erp-developers] Interface


        By menu items I mean the links to action a specific option.
          ----- Original Message -----=20
          From: skaill=20
          To: web...@li...=20
          Sent: Monday, August 02, 2004 11:34 AM
          Subject: Re: [Web-erp-developers] Interface


          Have you looked in the past day or two, Phil?  Some of your =
comments may be before I did a bunch of work.  Hopefully you have some =
time to look again.  No question marks anymore and they were only =
temporary before I was going to create a help graphic.  Anyway, I think =
the way you did with the one Help at the top is good as long as we =
document clearly, possibly in the first online help screen, that the =
help will change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

          The menus would be javascript.  However, I believe when I did =
testing in several browsers on this site I created www.goldenwitch.com =
they worked on all.  Some people with various browsers could try going =
to that site to see if the drop-down menus work perfectly.  It is =
minimal and very standard javascript.  I agree with avoiding javascript, =
java and any other language as much as possible but you can't make =
drop-down menus unless you have code at the client side.  I think ALL =
languages besides PHP, HTML and CSS should be optional in the config or =
elsewhere.

          I still have to get up with the cvs thing.  I have it =
installed but haven't tried it out.  When I do something it's all at =
once so one day soon I'll be doing cvs and will send you.

          I saw the user and database in the newest demo.  Something =
else I noticed though was that the Help gave an error.  Can't remember =
exactly where or why right now though.

          Steve

            ----- Original Message -----=20
            From: Daintrees=20
            To: web...@li...=20
            Sent: Sunday, August 01, 2004 4:15 PM
            Subject: Re: [Web-erp-developers] Interface


            I guess this would be java?
            If it could be made to work in all forms of java then it =
would be a useful addition - I have tried to avoid it so far and have no =
knowlege personally. It is nice not to depend on java for anything. I =
agree it would be good.

            I would like to clean the css if you send me the files.=20

            I like the vertical oreintation of the menus - I think it =
needs some spacing between the menu items - they all merge together.
            As previously mentioned I am not so keen on the =
preponderance of question marks. I think this is probably superseeded =
following our discussion on the help.

            I already added the user and database to the titles - in 2.9


            Phil



              ----- Original Message -----=20
              From: skaill=20
              To: web...@li...=20
              Sent: Monday, August 02, 2004 2:35 AM
              Subject: [Web-erp-developers] Interface


              I've been working with the interface quite a bit now.  For =
those who would like to see what I've done go to http://weberp.gocom.ca. =
 Please make many, many comments good or bad.

              While I've been doing this I fixed some incorrect code and =
cleaned it up, especially the css.  There were several places that had =
commands which weren't actually being used and in fact would lead =
someone to think that what they were seeing should be different.  This =
is typical and I'm no exception but I took the time to do some cleanup.  =
I think it is easier to read and understand now.

              Phil, if you like parts of this refined interface or all =
of it we can get it into the base product.  Let me know.

              I'm seriously thinking about adding code that will do =
drop-down menus and allow a user option to specify whether they see the =
interface displayed now or they see drop-down menus.  With the drop-down =
menus it would allow everything to be accessible all the time with =
little screen space taken up.  It also looks pro.  Plus the fast access =
options become basically irrelevant with drop-down menus.

              Steve

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

Some stuff such as heading/title is missing because I don't have 2.9 in =
my copy yet.  I will be incorporating those changes shortly.

Steve
  ----- Original Message -----=20
  From: Daintrees=20
  To: web...@li...=20
  Sent: Monday, August 02, 2004 4:09 PM
  Subject: Re: [Web-erp-developers] Interface


  Looks better on a 1024x768 than on a 600x800 screen. The inquiries and =
reports heading has to wrap onto two lines.

  The spaced links are less intimidating block of text too.

  Great!


  Notice that the heading/title of the page is missing?

  Phil
    ----- Original Message -----=20
    From: skaill=20
    To: web...@li...=20
    Sent: Tuesday, August 03, 2004 4:40 AM
    Subject: Re: [Web-erp-developers] Interface


    Refined some more at http://weberp.gocom.ca including spacing out =
the action links.

    Steve
      ----- Original Message -----=20
      From: Daintrees=20
      To: web...@li...=20
      Sent: Sunday, August 01, 2004 9:08 PM
      Subject: Re: [Web-erp-developers] Interface


      By menu items I mean the links to action a specific option.
        ----- Original Message -----=20
        From: skaill=20
        To: web...@li...=20
        Sent: Monday, August 02, 2004 11:34 AM
        Subject: Re: [Web-erp-developers] Interface


        Have you looked in the past day or two, Phil?  Some of your =
comments may be before I did a bunch of work.  Hopefully you have some =
time to look again.  No question marks anymore and they were only =
temporary before I was going to create a help graphic.  Anyway, I think =
the way you did with the one Help at the top is good as long as we =
document clearly, possibly in the first online help screen, that the =
help will change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

        The menus would be javascript.  However, I believe when I did =
testing in several browsers on this site I created www.goldenwitch.com =
they worked on all.  Some people with various browsers could try going =
to that site to see if the drop-down menus work perfectly.  It is =
minimal and very standard javascript.  I agree with avoiding javascript, =
java and any other language as much as possible but you can't make =
drop-down menus unless you have code at the client side.  I think ALL =
languages besides PHP, HTML and CSS should be optional in the config or =
elsewhere.

        I still have to get up with the cvs thing.  I have it installed =
but haven't tried it out.  When I do something it's all at once so one =
day soon I'll be doing cvs and will send you.

        I saw the user and database in the newest demo.  Something else =
I noticed though was that the Help gave an error.  Can't remember =
exactly where or why right now though.

        Steve

          ----- Original Message -----=20
          From: Daintrees=20
          To: web...@li...=20
          Sent: Sunday, August 01, 2004 4:15 PM
          Subject: Re: [Web-erp-developers] Interface


          I guess this would be java?
          If it could be made to work in all forms of java then it would =
be a useful addition - I have tried to avoid it so far and have no =
knowlege personally. It is nice not to depend on java for anything. I =
agree it would be good.

          I would like to clean the css if you send me the files.=20

          I like the vertical oreintation of the menus - I think it =
needs some spacing between the menu items - they all merge together.
          As previously mentioned I am not so keen on the preponderance =
of question marks. I think this is probably superseeded following our =
discussion on the help.

          I already added the user and database to the titles - in 2.9


          Phil



            ----- Original Message -----=20
            From: skaill=20
            To: web...@li...=20
            Sent: Monday, August 02, 2004 2:35 AM
            Subject: [Web-erp-developers] Interface


            I've been working with the interface quite a bit now.  For =
those who would like to see what I've done go to http://weberp.gocom.ca. =
 Please make many, many comments good or bad.

            While I've been doing this I fixed some incorrect code and =
cleaned it up, especially the css.  There were several places that had =
commands which weren't actually being used and in fact would lead =
someone to think that what they were seeing should be different.  This =
is typical and I'm no exception but I took the time to do some cleanup.  =
I think it is easier to read and understand now.

            Phil, if you like parts of this refined interface or all of =
it we can get it into the base product.  Let me know.

            I'm seriously thinking about adding code that will do =
drop-down menus and allow a user option to specify whether they see the =
interface displayed now or they see drop-down menus.  With the drop-down =
menus it would allow everything to be accessible all the time with =
little screen space taken up.  It also looks pro.  Plus the fast access =
options become basically irrelevant with drop-down menus.

            Steve

Re: [Web-erp-developers] Fw: Italian Translation of web-erp

[skaill <sk...@ro...>]

Here is more information about the GNU gettext...

http://www.gnu.org/software/gettext/gettext.html

Just starting to read it myself but looks promising.

Steve

----- Original Message ----- 
From: "Daintrees" <p.d...@pa...>
To: <web...@li...>
Cc: <luc...@pd...>
Sent: Monday, August 02, 2004 4:21 PM
Subject: [Web-erp-developers] Fw: Italian Translation of web-erp


Luca,

I am not sure if you have joined the developers list, but I have forwareded
this email to them because I would like to run your proposal past the other
interested and knowledgeable folk - hope you dont mind!

We have a table of each script - that was added in 2.9 for the context
sensitive help (currently not language specific) - each script is given a
unique id - this may also be helpful for security Steve - the idea of
retrieving just the labels for the script being run is appealing as is
having a user interface for translators that doesnt involve editing files.
You have some good points. The best point of all - you are prepared to do a
lot of work for the project - most appreciated.

Lets just see if there are any other opinions/pitfalls that the rest of the
team see - so we dont trip and fall on this.

Phil

----- Original Message ----- 
From: "ing. Luca Turlon Donà" <luc...@pd...>
To: "Phil Daintree" <p.d...@pa...>
Sent: Tuesday, August 03, 2004 12:11 AM
Subject: Re: Italian Translation of web-erp


> Hi Phil.
> I've been reading thru your mail several times before answering, cause
wanted
> to be sure to understand every single issue ou pointed out.
>
> The main consideration that comes out is that your approach is very
similar to
> mine, i.e.:
> -You are proposing a function call, I am proposing to use an array with a
> literal index.
> -You are proposing several files with the translation, i am proposing
several
> groups of rows in a table.
>
> Firts let me explain one thing: my idea consists in loading an array from
the
> db, i.e.: in the beginning of every page I make a bulk load of all the
labels
> in the language that has to be shown. So we do not have a full read cycle
> (connect-query-parse the query, disconnect) on the db for every single
label
> in the page. We read everything at the beginning, load it in the lang
array
> and then use the lang array. This should address the second concern that
you
> put in your email. There is another thing: if we add a column on the db
table,
> containing the script (or an unique code which identifies the script) that
is
> going to be rendered we can achieve two more thing: first we can load just
the
> labels used in that script, reducing the size of the array. Secondly we
will
> have a documentation of what is shown in every page.
>
> Regarding the other concern, i.e. the smallness of 30 chars for a label
> identifier, I believe that i could enlarge that column to a wider string:
i do
> not see any problem on this.
>
> The last thing you say, that is the code should be easy understandable.
Maybe
> you're right in considering the code easier to read having a full english
> label, but I think that a label identifier with some comment could do the
> same. In this way you could avoid the problem you mentioned about changes
in
> the english labels.
>
> Please now let me tell some other things about the "function" approach:
> a) there is no other way than creating a php script to translate the
> application. With the db approach I could create a page to let any kind of
> user (not only a PHP programmer) manage the translation
> b) it can become tough managing any new version of the system: with the db
you
> can query and see how many entries you have for each language, and you can
> easily identify which labels has to be translated. With the included file
> approach you have to work on the files, hoping that every file is written
with
> exactly the same approach.
> c) Since you must delegate people to translate (unless you know at least
15
> languages) you can loose control on the code: what if a russian sends you
an
> email saying that the system not working, just because the russian
translator
> forgot a ";" in his code? With the db approach the worst thing that could
> happen is a wrong translation or something written in English, but not
> something that halts the system.
> d) With the db you have a sort of documentation, which can help in
creating
> help files...
> e) it is at any time possible to automatically generate any language
script,
> i.e a language/italiano.php can be generated from the db and we can switch
to
> your "function" approach.
> f) ther is another thing regarding the usage of the entire english label
as a
> parameter: imagine if you forget to put the function call. With the label
> identifier you immediately see that there is something difficult to read
on
> the page. With the full english label you may even not notice the error.
>
>
> Finally: I do believe that the language variable should be kept, in the
> future, in the session of the user, having each user working with his/her
own
> language. For now I am just using a default language, but in the future it
can
> be changed.
>
> One very last thing: I have to work on it, 'cause these friends of mine
needs
> it, and I will work on the application making it multilanguage. I will go
thru
> the entire application, populating the db tables and changing the  scripts
> where needed. After I will finish my job, I believe by the end of
september, I
> am going to send you the result of my job: thus you'll get a finished a
work,
> and you'd be not worried by having something not finished. The only thing
is
> to understand what has changed from noew (or better from the 2.9 release
of
> the system) till the end of september.
>
> Luca
>
> Scrive Phil Daintree <p.d...@pa...>:
>
> > Hi Luca,
> >
> > There has been quite a bit of a discussion about multi-language - there
> > are a lot of issues. Maybe I scare too easily, but it seems like a
> > massive undertaking :-O
> >
> > Thanks so much for considering what is really quite a sizable project
> > here. The other fear factor in taking this sort of thing on is if we
> > start it I am the muggins that has a stuffed system if we can't finish
> > it. It sure would be great to make web-erp multi-language.
> >
> > I see the way you are heading with what you started .... my over-riding
> > and BIG worry in going to multi-language is that the code might become
> > more difficult to make sense of (of course it being in English must be
> > quite a snag for those who use another language anyway). Under the
> > scenario you are proposing we would, I guess have a varchar(30)
> > description for the label that would be substituted by the TEXT field.
> > There a couple of reasons why I'm not that keen on this approach:
> >
> > 1. 30 characters isn't much to describe the text variable. The full
> > context that the label provides I think significantly improves the
> > ability to understand code.
> > 2. If this requires a query for every label then this could be quite an
> > overhead on the db and a potential delay for the user. (all users).
> >
> > Of the approaches discussed in the developers list - there is an archive
> > of this http://sourceforge.net/mailarchive/forum.php?forum_id=34088
> >
> > I prefer Steve Kaill's approach and the approach used in open-accounting
> > ie enclosing the the full label in a function call eg.
> >
> > echo language("This is how I rekon we should do multi-language so the
> > code remains relatively easy to read");
> >
> > the language function returns the language string required by the user.
> >
> > We hold a $_SESSION['language'] variable which is stored in the
> > www_users table and retreived at the time of login.
> >
> > This language variable would be the same name as the file to include
> > under a new languages directory.
> >
> > The function language would be in this include directory.
> >
> > The function language then takes the text of the english label as a
> > parameter - the $SESSION['language'] is defined as global inside this
> > function and returns the the language string appropriate - if there is
> > no match for the string parameter passed then the parameter ie the
> > english label is returned.
> >
> > The english language function in languages/english.php would just return
> > the parameter itself.
> >
> > I have not gone down the track of considering if the label substitution
> > is done using an array or what .... I would probably take a look at
> > open-accounting logic.
> >
> > This approach does retain a critical requirement for webERP ie that of
> > easily understandable code.
> >
> > All approaches have their down side -
> >
> > 1. This puts the overhead on the web-server/ php interpreter. However,
> > this is pretty fast.However,potentially significant memory is required -
> > for what I have tried desperately to be minimalist in terms of resources
> > required to run it.
> >
> > 2. Anyone changing the english labels will stuff up the translation file
> > ie the include file of strings in english with the equivalent language
> > string!
> >
> > Do you see any other snags with this approach Luca?
> > Could you consider a slightly different approach?
> >
> > Phil
> >
> >
> > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > wrote:
> > > Hello Phil,
> > > I've started to work on it.
> > > Here is how I want to address the issue.
> > > First I am going to create a table containing all the labels
> > >
> > > CREATE TABLE `languages` (
> > >   `id` bigint(20) NOT NULL auto_increment,
> > >   `LANGID` varchar(15) NOT NULL default '',
> > >   `TEXTID` varchar(30) NOT NULL default '',
> > >   `TEXT` varchar(255) NOT NULL default '',
> > >   UNIQUE KEY `id` (`id`)
> > > ) TYPE=InnoDB COMMENT='Table containing labels to be showed on the
> > pages';
> > >
> > > (I don't think InnoDB is necessary for this table, since it is only
> > read by
> > > normal users, and loaded by installer: i kept that type only for
> > compatibility
> > > with your design).
> > >
> > > TEXTID is a code that identifies a specific label in very page. With
> > some work
> > > we can undertsand if the same label is going to be used on diffrent
> > pages.
> > > TEXT is the text that is going to appear on the browser.
> > >
> > > On the config.php file I've inserted another variable:
> > > $DefaultLanguage="ITALIANO"; //of course you can put ENGLISH
> > >
> > > In session.inc i've inserted this line
> > >     include ("language.php");
> > > just after
> > >     include("includes/ConnectDB.inc");
> > >
> > > As you can see in the attachment, language.php loads an array named
> > $lang with
> > > the contents of the table "languages".
> > > By default it loads the $DefaultLanguage, but if the variable is not
> > defined it
> > > loads the English table.
> > >
> > > Then I simply substitute all the labels around the php and html code
> > with the
> > > corresponding entry in the $lang array.
> > > As an example you can see in the attached login.php file the following
> > lines: 9,
> > > 53, 57, 66.
> > >
> > > Having the labels in a db table can lead to another enhancement: every
> > user can
> > > choose his/her own language. This could be useful for companies having
> > clients
> > > spreaded around various countries....
> > >
> > > What do you think about?
> > > Can we arrange my small improvement with the future developement you
> > are making
> > > in web-erp?
> > >
> > > Luca
> > >
> > >
> > > Scrive Phil Daintree <p.d...@pa...>:
> > >
> > > > There has been some discussion about multi-language recently on the
> > > > list.
> > > >
> > > > I am prepared to maintain a rigorous log of changes to scripts.
> > Perhaps
> > > > I could produce a diff file for all changes on each release but you
> > > > would have to apply these changes to the italian version. I have had
> > a
> > > > similar request from a spanish speaking person.
> > > >
> > > > An Italian version would be good.
> > > >
> > > > web-erp is not ideally suited to multi-language as you point out
> > since
> > > > all labels, print and echo statements would need to be modified and
> > > > changes in the core scripts would need to be applied to each
> > language's
> > > > scripts manually.
> > > >
> > > > Phil
> > > >
> > > >
> > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > > > wrote:
> > > > > Dear Phil,
> > > > > a couple of friends, who ar starting up a new fashion company here
> > in
> > > > italy,
> > > > > are very interested in using the application you developed.
> > > > >
> > > > > Since they're not very acquainted with the english language and
> > > > jargon, i need
> > > > > to translate the application for them.
> > > > >
> > > > > I have various ways to do this: one is to simply browse the code
> > and
> > > > change
> > > > > all the labels into italian. Doing so, i am very concerned about
> > > > everytime you
> > > > > give a new release: at that time I have to check every change in
> > every
> > > > single
> > > > > file.
> > > > > The other one is to modify the code in order to have a separate
> > place
> > > > in which
> > > > > labels and all the language-dependent stuff are stored. This can
> > be a
> > > > DB table
> > > > > or a file... i still don't know.
> > > > > Before starting this, i need to know a couple of things:
> > > > > First: are you going to do what I would like to do? In this case
> > when
> > > > do you
> > > > > think you will release a multilingual version of web-erp? And: do
> > you
> > > > need any
> > > > > help? I'd be happy to help in any way.
> > > > > Second: if you're not going to do the multilingual version, can I
> > work
> > > > on it?
> > > > > Can we synch our two different tracks (the improvement of the
> > system
> > > > that
> > > > > maybe you are doing and my translation-multilingual effort)?
> > > > >
> > > > > Please give me an answer on this, since i am strongly sponsoring
> > your
> > > > > product...
> > > > > Best Regards,
> > > > > Luca
> > > > >
> > > > > PS: I am working on the translation of the manual. When finished,
> > I'll
> > > > send it
> > > > > to you.
> > > > >
> > > >
> >
>




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Web-erp-developers mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] Fw: Italian Translation of web-erp

[Stins, D. <DR...@Zi...>]

Great that Luca would like to implement this functionality.

When this solution does not what we expect, then we can always consider t=
o
try to create a generate script which generate a script to fill the array
from the database which Luca is creating or generate some other better
solution.

Performance might vary per version of apache, linux, mysql, php and is no=
t
always logical. Like I read that read that session variables are always r=
ead
from disks (slow) and you might think that it is faster because you  migh=
t
think that it you have tto load only once the translation array compared =
to
loading it for every page again (solution of Luca). When the loading of t=
he
array for every page is cached in RAM, then it's faster then loading once=
 in
session variables.

Luca: Let's see what happens! Success!

With best regards,

Dick Stins
----- Original Message -----
From: "Daintrees" <p.d...@pa...>
To: <web...@li...>
Cc: <luc...@pd...>
Sent: Monday, August 02, 2004 10:21 PM
Subject: [Web-erp-developers] Fw: Italian Translation of web-erp


Luca,

I am not sure if you have joined the developers list, but I have forwared=
ed
this email to them because I would like to run your proposal past the oth=
er
interested and knowledgeable folk - hope you dont mind!

We have a table of each script - that was added in 2.9 for the context
sensitive help (currently not language specific) - each script is given a
unique id - this may also be helpful for security Steve - the idea of
retrieving just the labels for the script being run is appealing as is
having a user interface for translators that doesnt involve editing files=
.
You have some good points. The best point of all - you are prepared to do=
 a
lot of work for the project - most appreciated.

Lets just see if there are any other opinions/pitfalls that the rest of t=
he
team see - so we dont trip and fall on this.

Phil

----- Original Message -----
From: "ing. Luca Turlon Don=E0" <luc...@pd...>
To: "Phil Daintree" <p.d...@pa...>
Sent: Tuesday, August 03, 2004 12:11 AM
Subject: Re: Italian Translation of web-erp


> Hi Phil.
> I've been reading thru your mail several times before answering, cause
wanted
> to be sure to understand every single issue ou pointed out.
>
> The main consideration that comes out is that your approach is very
similar to
> mine, i.e.:
> -You are proposing a function call, I am proposing to use an array with=
 a
> literal index.
> -You are proposing several files with the translation, i am proposing
several
> groups of rows in a table.
>
> Firts let me explain one thing: my idea consists in loading an array fr=
om
the
> db, i.e.: in the beginning of every page I make a bulk load of all the
labels
> in the language that has to be shown. So we do not have a full read cyc=
le
> (connect-query-parse the query, disconnect) on the db for every single
label
> in the page. We read everything at the beginning, load it in the lang
array
> and then use the lang array. This should address the second concern tha=
t
you
> put in your email. There is another thing: if we add a column on the db
table,
> containing the script (or an unique code which identifies the script) t=
hat
is
> going to be rendered we can achieve two more thing: first we can load j=
ust
the
> labels used in that script, reducing the size of the array. Secondly we
will
> have a documentation of what is shown in every page.
>
> Regarding the other concern, i.e. the smallness of 30 chars for a label
> identifier, I believe that i could enlarge that column to a wider strin=
g:
i do
> not see any problem on this.
>
> The last thing you say, that is the code should be easy understandable.
Maybe
> you're right in considering the code easier to read having a full engli=
sh
> label, but I think that a label identifier with some comment could do t=
he
> same. In this way you could avoid the problem you mentioned about chang=
es
in
> the english labels.
>
> Please now let me tell some other things about the "function" approach:
> a) there is no other way than creating a php script to translate the
> application. With the db approach I could create a page to let any kind=
 of
> user (not only a PHP programmer) manage the translation
> b) it can become tough managing any new version of the system: with the=
 db
you
> can query and see how many entries you have for each language, and you =
can
> easily identify which labels has to be translated. With the included fi=
le
> approach you have to work on the files, hoping that every file is writt=
en
with
> exactly the same approach.
> c) Since you must delegate people to translate (unless you know at leas=
t
15
> languages) you can loose control on the code: what if a russian sends y=
ou
an
> email saying that the system not working, just because the russian
translator
> forgot a ";" in his code? With the db approach the worst thing that cou=
ld
> happen is a wrong translation or something written in English, but not
> something that halts the system.
> d) With the db you have a sort of documentation, which can help in
creating
> help files...
> e) it is at any time possible to automatically generate any language
script,
> i.e a language/italiano.php can be generated from the db and we can swi=
tch
to
> your "function" approach.
> f) ther is another thing regarding the usage of the entire english labe=
l
as a
> parameter: imagine if you forget to put the function call. With the lab=
el
> identifier you immediately see that there is something difficult to rea=
d
on
> the page. With the full english label you may even not notice the error=
.
>
>
> Finally: I do believe that the language variable should be kept, in the
> future, in the session of the user, having each user working with his/h=
er
own
> language. For now I am just using a default language, but in the future=
 it
can
> be changed.
>
> One very last thing: I have to work on it, 'cause these friends of mine
needs
> it, and I will work on the application making it multilanguage. I will =
go
thru
> the entire application, populating the db tables and changing the  scri=
pts
> where needed. After I will finish my job, I believe by the end of
september, I
> am going to send you the result of my job: thus you'll get a finished a
work,
> and you'd be not worried by having something not finished. The only thi=
ng
is
> to understand what has changed from noew (or better from the 2.9 releas=
e
of
> the system) till the end of september.
>
> Luca
>
> Scrive Phil Daintree <p.d...@pa...>:
>
> > Hi Luca,
> >
> > There has been quite a bit of a discussion about multi-language - the=
re
> > are a lot of issues. Maybe I scare too easily, but it seems like a
> > massive undertaking :-O
> >
> > Thanks so much for considering what is really quite a sizable project
> > here. The other fear factor in taking this sort of thing on is if we
> > start it I am the muggins that has a stuffed system if we can't finis=
h
> > it. It sure would be great to make web-erp multi-language.
> >
> > I see the way you are heading with what you started .... my over-ridi=
ng
> > and BIG worry in going to multi-language is that the code might becom=
e
> > more difficult to make sense of (of course it being in English must b=
e
> > quite a snag for those who use another language anyway). Under the
> > scenario you are proposing we would, I guess have a varchar(30)
> > description for the label that would be substituted by the TEXT field=
.
> > There a couple of reasons why I'm not that keen on this approach:
> >
> > 1. 30 characters isn't much to describe the text variable. The full
> > context that the label provides I think significantly improves the
> > ability to understand code.
> > 2. If this requires a query for every label then this could be quite =
an
> > overhead on the db and a potential delay for the user. (all users).
> >
> > Of the approaches discussed in the developers list - there is an arch=
ive
> > of this http://sourceforge.net/mailarchive/forum.php?forum_id=3D34088
> >
> > I prefer Steve Kaill's approach and the approach used in open-account=
ing
> > ie enclosing the the full label in a function call eg.
> >
> > echo language("This is how I rekon we should do multi-language so the
> > code remains relatively easy to read");
> >
> > the language function returns the language string required by the use=
r.
> >
> > We hold a $_SESSION['language'] variable which is stored in the
> > www_users table and retreived at the time of login.
> >
> > This language variable would be the same name as the file to include
> > under a new languages directory.
> >
> > The function language would be in this include directory.
> >
> > The function language then takes the text of the english label as a
> > parameter - the $SESSION['language'] is defined as global inside this
> > function and returns the the language string appropriate - if there i=
s
> > no match for the string parameter passed then the parameter ie the
> > english label is returned.
> >
> > The english language function in languages/english.php would just ret=
urn
> > the parameter itself.
> >
> > I have not gone down the track of considering if the label substituti=
on
> > is done using an array or what .... I would probably take a look at
> > open-accounting logic.
> >
> > This approach does retain a critical requirement for webERP ie that o=
f
> > easily understandable code.
> >
> > All approaches have their down side -
> >
> > 1. This puts the overhead on the web-server/ php interpreter. However=
,
> > this is pretty fast.However,potentially significant memory is require=
d -
> > for what I have tried desperately to be minimalist in terms of resour=
ces
> > required to run it.
> >
> > 2. Anyone changing the english labels will stuff up the translation f=
ile
> > ie the include file of strings in english with the equivalent languag=
e
> > string!
> >
> > Do you see any other snags with this approach Luca?
> > Could you consider a slightly different approach?
> >
> > Phil
> >
> >
> > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=3D?ISO-8859-1?Q?lon_Don=3D=
E0?=3D
> > wrote:
> > > Hello Phil,
> > > I've started to work on it.
> > > Here is how I want to address the issue.
> > > First I am going to create a table containing all the labels
> > >
> > > CREATE TABLE `languages` (
> > >   `id` bigint(20) NOT NULL auto_increment,
> > >   `LANGID` varchar(15) NOT NULL default '',
> > >   `TEXTID` varchar(30) NOT NULL default '',
> > >   `TEXT` varchar(255) NOT NULL default '',
> > >   UNIQUE KEY `id` (`id`)
> > > ) TYPE=3DInnoDB COMMENT=3D'Table containing labels to be showed on =
the
> > pages';
> > >
> > > (I don't think InnoDB is necessary for this table, since it is only
> > read by
> > > normal users, and loaded by installer: i kept that type only for
> > compatibility
> > > with your design).
> > >
> > > TEXTID is a code that identifies a specific label in very page. Wit=
h
> > some work
> > > we can undertsand if the same label is going to be used on diffrent
> > pages.
> > > TEXT is the text that is going to appear on the browser.
> > >
> > > On the config.php file I've inserted another variable:
> > > $DefaultLanguage=3D"ITALIANO"; //of course you can put ENGLISH
> > >
> > > In session.inc i've inserted this line
> > >     include ("language.php");
> > > just after
> > >     include("includes/ConnectDB.inc");
> > >
> > > As you can see in the attachment, language.php loads an array named
> > $lang with
> > > the contents of the table "languages".
> > > By default it loads the $DefaultLanguage, but if the variable is no=
t
> > defined it
> > > loads the English table.
> > >
> > > Then I simply substitute all the labels around the php and html cod=
e
> > with the
> > > corresponding entry in the $lang array.
> > > As an example you can see in the attached login.php file the follow=
ing
> > lines: 9,
> > > 53, 57, 66.
> > >
> > > Having the labels in a db table can lead to another enhancement: ev=
ery
> > user can
> > > choose his/her own language. This could be useful for companies hav=
ing
> > clients
> > > spreaded around various countries....
> > >
> > > What do you think about?
> > > Can we arrange my small improvement with the future developement yo=
u
> > are making
> > > in web-erp?
> > >
> > > Luca
> > >
> > >
> > > Scrive Phil Daintree <p.d...@pa...>:
> > >
> > > > There has been some discussion about multi-language recently on t=
he
> > > > list.
> > > >
> > > > I am prepared to maintain a rigorous log of changes to scripts.
> > Perhaps
> > > > I could produce a diff file for all changes on each release but y=
ou
> > > > would have to apply these changes to the italian version. I have =
had
> > a
> > > > similar request from a spanish speaking person.
> > > >
> > > > An Italian version would be good.
> > > >
> > > > web-erp is not ideally suited to multi-language as you point out
> > since
> > > > all labels, print and echo statements would need to be modified a=
nd
> > > > changes in the core scripts would need to be applied to each
> > language's
> > > > scripts manually.
> > > >
> > > > Phil
> > > >
> > > >
> > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > Tur=3D?ISO-8859-1?Q?lon_Don=3DE0?=3D
> > > > wrote:
> > > > > Dear Phil,
> > > > > a couple of friends, who ar starting up a new fashion company h=
ere
> > in
> > > > italy,
> > > > > are very interested in using the application you developed.
> > > > >
> > > > > Since they're not very acquainted with the english language and
> > > > jargon, i need
> > > > > to translate the application for them.
> > > > >
> > > > > I have various ways to do this: one is to simply browse the cod=
e
> > and
> > > > change
> > > > > all the labels into italian. Doing so, i am very concerned abou=
t
> > > > everytime you
> > > > > give a new release: at that time I have to check every change i=
n
> > every
> > > > single
> > > > > file.
> > > > > The other one is to modify the code in order to have a separate
> > place
> > > > in which
> > > > > labels and all the language-dependent stuff are stored. This ca=
n
> > be a
> > > > DB table
> > > > > or a file... i still don't know.
> > > > > Before starting this, i need to know a couple of things:
> > > > > First: are you going to do what I would like to do? In this cas=
e
> > when
> > > > do you
> > > > > think you will release a multilingual version of web-erp? And: =
do
> > you
> > > > need any
> > > > > help? I'd be happy to help in any way.
> > > > > Second: if you're not going to do the multilingual version, can=
 I
> > work
> > > > on it?
> > > > > Can we synch our two different tracks (the improvement of the
> > system
> > > > that
> > > > > maybe you are doing and my translation-multilingual effort)?
> > > > >
> > > > > Please give me an answer on this, since i am strongly sponsorin=
g
> > your
> > > > > product...
> > > > > Best Regards,
> > > > > Luca
> > > > >
> > > > > PS: I am working on the translation of the manual. When finishe=
d,
> > I'll
> > > > send it
> > > > > to you.
> > > > >
> > > >
> >
>




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Web-erp-developers mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] Fw: Italian Translation of web-erp

[skaill <sk...@ro...>]

This is an area that we will need to work on as well.  If Luca wants to "get
together" at some point to work on this I am available.

I would point out to Luca that keeping the original English strings in the
code instead of using an identifier keeps the code WAY more readable.
That's my opinion after having worked extensively with a product that did it
with identifiers.  Code is scary to read when it has identifiers instead of
literals.  Many will be thrown off by doing that.

I have recently discovered a function in PHP called gettext which may be for
exactly what we are trying to do.  I don't know enough about it but before
doing our own coding for Multilanguage it would be nice to see if the built
in gettext functionality will do it.

Just guessing but I think loading the entire language file at the beginning
of each page may be much slower than doing a few reads within one page.  A
few lines versus hundreds to thousands.  Plus the memory for each user would
be way more.  Here's an idea that actually ends up a modified version of
Luca's suggestion to keep the page number in the db.  Have an array of
strings at the top of each page where those strings are the strings used
within the page.  Call a language function that retrieves and returns all of
these at the page beginning.  When language(...) is called within the page,
it first looks to see if the string was looked up already and uses that
otherwise goes out to retrieve from the db, file or wherever.  This will
minimize the amount needing to be looked up yet look it up (or most of it)
all at once as Luca is suggesting.

We can build in whatever is changed until September very easily.  It's just
important to know which version Luca started on.

I agree that db storage is the best for the Multilanguage information over
another way such as file.

Steve

----- Original Message ----- 
From: "Daintrees" <p.d...@pa...>
To: <web...@li...>
Cc: <luc...@pd...>
Sent: Monday, August 02, 2004 4:21 PM
Subject: [Web-erp-developers] Fw: Italian Translation of web-erp


Luca,

I am not sure if you have joined the developers list, but I have forwareded
this email to them because I would like to run your proposal past the other
interested and knowledgeable folk - hope you dont mind!

We have a table of each script - that was added in 2.9 for the context
sensitive help (currently not language specific) - each script is given a
unique id - this may also be helpful for security Steve - the idea of
retrieving just the labels for the script being run is appealing as is
having a user interface for translators that doesnt involve editing files.
You have some good points. The best point of all - you are prepared to do a
lot of work for the project - most appreciated.

Lets just see if there are any other opinions/pitfalls that the rest of the
team see - so we dont trip and fall on this.

Phil

----- Original Message ----- 
From: "ing. Luca Turlon Donà" <luc...@pd...>
To: "Phil Daintree" <p.d...@pa...>
Sent: Tuesday, August 03, 2004 12:11 AM
Subject: Re: Italian Translation of web-erp


> Hi Phil.
> I've been reading thru your mail several times before answering, cause
wanted
> to be sure to understand every single issue ou pointed out.
>
> The main consideration that comes out is that your approach is very
similar to
> mine, i.e.:
> -You are proposing a function call, I am proposing to use an array with a
> literal index.
> -You are proposing several files with the translation, i am proposing
several
> groups of rows in a table.
>
> Firts let me explain one thing: my idea consists in loading an array from
the
> db, i.e.: in the beginning of every page I make a bulk load of all the
labels
> in the language that has to be shown. So we do not have a full read cycle
> (connect-query-parse the query, disconnect) on the db for every single
label
> in the page. We read everything at the beginning, load it in the lang
array
> and then use the lang array. This should address the second concern that
you
> put in your email. There is another thing: if we add a column on the db
table,
> containing the script (or an unique code which identifies the script) that
is
> going to be rendered we can achieve two more thing: first we can load just
the
> labels used in that script, reducing the size of the array. Secondly we
will
> have a documentation of what is shown in every page.
>
> Regarding the other concern, i.e. the smallness of 30 chars for a label
> identifier, I believe that i could enlarge that column to a wider string:
i do
> not see any problem on this.
>
> The last thing you say, that is the code should be easy understandable.
Maybe
> you're right in considering the code easier to read having a full english
> label, but I think that a label identifier with some comment could do the
> same. In this way you could avoid the problem you mentioned about changes
in
> the english labels.
>
> Please now let me tell some other things about the "function" approach:
> a) there is no other way than creating a php script to translate the
> application. With the db approach I could create a page to let any kind of
> user (not only a PHP programmer) manage the translation
> b) it can become tough managing any new version of the system: with the db
you
> can query and see how many entries you have for each language, and you can
> easily identify which labels has to be translated. With the included file
> approach you have to work on the files, hoping that every file is written
with
> exactly the same approach.
> c) Since you must delegate people to translate (unless you know at least
15
> languages) you can loose control on the code: what if a russian sends you
an
> email saying that the system not working, just because the russian
translator
> forgot a ";" in his code? With the db approach the worst thing that could
> happen is a wrong translation or something written in English, but not
> something that halts the system.
> d) With the db you have a sort of documentation, which can help in
creating
> help files...
> e) it is at any time possible to automatically generate any language
script,
> i.e a language/italiano.php can be generated from the db and we can switch
to
> your "function" approach.
> f) ther is another thing regarding the usage of the entire english label
as a
> parameter: imagine if you forget to put the function call. With the label
> identifier you immediately see that there is something difficult to read
on
> the page. With the full english label you may even not notice the error.
>
>
> Finally: I do believe that the language variable should be kept, in the
> future, in the session of the user, having each user working with his/her
own
> language. For now I am just using a default language, but in the future it
can
> be changed.
>
> One very last thing: I have to work on it, 'cause these friends of mine
needs
> it, and I will work on the application making it multilanguage. I will go
thru
> the entire application, populating the db tables and changing the  scripts
> where needed. After I will finish my job, I believe by the end of
september, I
> am going to send you the result of my job: thus you'll get a finished a
work,
> and you'd be not worried by having something not finished. The only thing
is
> to understand what has changed from noew (or better from the 2.9 release
of
> the system) till the end of september.
>
> Luca
>
> Scrive Phil Daintree <p.d...@pa...>:
>
> > Hi Luca,
> >
> > There has been quite a bit of a discussion about multi-language - there
> > are a lot of issues. Maybe I scare too easily, but it seems like a
> > massive undertaking :-O
> >
> > Thanks so much for considering what is really quite a sizable project
> > here. The other fear factor in taking this sort of thing on is if we
> > start it I am the muggins that has a stuffed system if we can't finish
> > it. It sure would be great to make web-erp multi-language.
> >
> > I see the way you are heading with what you started .... my over-riding
> > and BIG worry in going to multi-language is that the code might become
> > more difficult to make sense of (of course it being in English must be
> > quite a snag for those who use another language anyway). Under the
> > scenario you are proposing we would, I guess have a varchar(30)
> > description for the label that would be substituted by the TEXT field.
> > There a couple of reasons why I'm not that keen on this approach:
> >
> > 1. 30 characters isn't much to describe the text variable. The full
> > context that the label provides I think significantly improves the
> > ability to understand code.
> > 2. If this requires a query for every label then this could be quite an
> > overhead on the db and a potential delay for the user. (all users).
> >
> > Of the approaches discussed in the developers list - there is an archive
> > of this http://sourceforge.net/mailarchive/forum.php?forum_id=34088
> >
> > I prefer Steve Kaill's approach and the approach used in open-accounting
> > ie enclosing the the full label in a function call eg.
> >
> > echo language("This is how I rekon we should do multi-language so the
> > code remains relatively easy to read");
> >
> > the language function returns the language string required by the user.
> >
> > We hold a $_SESSION['language'] variable which is stored in the
> > www_users table and retreived at the time of login.
> >
> > This language variable would be the same name as the file to include
> > under a new languages directory.
> >
> > The function language would be in this include directory.
> >
> > The function language then takes the text of the english label as a
> > parameter - the $SESSION['language'] is defined as global inside this
> > function and returns the the language string appropriate - if there is
> > no match for the string parameter passed then the parameter ie the
> > english label is returned.
> >
> > The english language function in languages/english.php would just return
> > the parameter itself.
> >
> > I have not gone down the track of considering if the label substitution
> > is done using an array or what .... I would probably take a look at
> > open-accounting logic.
> >
> > This approach does retain a critical requirement for webERP ie that of
> > easily understandable code.
> >
> > All approaches have their down side -
> >
> > 1. This puts the overhead on the web-server/ php interpreter. However,
> > this is pretty fast.However,potentially significant memory is required -
> > for what I have tried desperately to be minimalist in terms of resources
> > required to run it.
> >
> > 2. Anyone changing the english labels will stuff up the translation file
> > ie the include file of strings in english with the equivalent language
> > string!
> >
> > Do you see any other snags with this approach Luca?
> > Could you consider a slightly different approach?
> >
> > Phil
> >
> >
> > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > wrote:
> > > Hello Phil,
> > > I've started to work on it.
> > > Here is how I want to address the issue.
> > > First I am going to create a table containing all the labels
> > >
> > > CREATE TABLE `languages` (
> > >   `id` bigint(20) NOT NULL auto_increment,
> > >   `LANGID` varchar(15) NOT NULL default '',
> > >   `TEXTID` varchar(30) NOT NULL default '',
> > >   `TEXT` varchar(255) NOT NULL default '',
> > >   UNIQUE KEY `id` (`id`)
> > > ) TYPE=InnoDB COMMENT='Table containing labels to be showed on the
> > pages';
> > >
> > > (I don't think InnoDB is necessary for this table, since it is only
> > read by
> > > normal users, and loaded by installer: i kept that type only for
> > compatibility
> > > with your design).
> > >
> > > TEXTID is a code that identifies a specific label in very page. With
> > some work
> > > we can undertsand if the same label is going to be used on diffrent
> > pages.
> > > TEXT is the text that is going to appear on the browser.
> > >
> > > On the config.php file I've inserted another variable:
> > > $DefaultLanguage="ITALIANO"; //of course you can put ENGLISH
> > >
> > > In session.inc i've inserted this line
> > >     include ("language.php");
> > > just after
> > >     include("includes/ConnectDB.inc");
> > >
> > > As you can see in the attachment, language.php loads an array named
> > $lang with
> > > the contents of the table "languages".
> > > By default it loads the $DefaultLanguage, but if the variable is not
> > defined it
> > > loads the English table.
> > >
> > > Then I simply substitute all the labels around the php and html code
> > with the
> > > corresponding entry in the $lang array.
> > > As an example you can see in the attached login.php file the following
> > lines: 9,
> > > 53, 57, 66.
> > >
> > > Having the labels in a db table can lead to another enhancement: every
> > user can
> > > choose his/her own language. This could be useful for companies having
> > clients
> > > spreaded around various countries....
> > >
> > > What do you think about?
> > > Can we arrange my small improvement with the future developement you
> > are making
> > > in web-erp?
> > >
> > > Luca
> > >
> > >
> > > Scrive Phil Daintree <p.d...@pa...>:
> > >
> > > > There has been some discussion about multi-language recently on the
> > > > list.
> > > >
> > > > I am prepared to maintain a rigorous log of changes to scripts.
> > Perhaps
> > > > I could produce a diff file for all changes on each release but you
> > > > would have to apply these changes to the italian version. I have had
> > a
> > > > similar request from a spanish speaking person.
> > > >
> > > > An Italian version would be good.
> > > >
> > > > web-erp is not ideally suited to multi-language as you point out
> > since
> > > > all labels, print and echo statements would need to be modified and
> > > > changes in the core scripts would need to be applied to each
> > language's
> > > > scripts manually.
> > > >
> > > > Phil
> > > >
> > > >
> > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > Tur=?ISO-8859-1?Q?lon_Don=E0?=
> > > > wrote:
> > > > > Dear Phil,
> > > > > a couple of friends, who ar starting up a new fashion company here
> > in
> > > > italy,
> > > > > are very interested in using the application you developed.
> > > > >
> > > > > Since they're not very acquainted with the english language and
> > > > jargon, i need
> > > > > to translate the application for them.
> > > > >
> > > > > I have various ways to do this: one is to simply browse the code
> > and
> > > > change
> > > > > all the labels into italian. Doing so, i am very concerned about
> > > > everytime you
> > > > > give a new release: at that time I have to check every change in
> > every
> > > > single
> > > > > file.
> > > > > The other one is to modify the code in order to have a separate
> > place
> > > > in which
> > > > > labels and all the language-dependent stuff are stored. This can
> > be a
> > > > DB table
> > > > > or a file... i still don't know.
> > > > > Before starting this, i need to know a couple of things:
> > > > > First: are you going to do what I would like to do? In this case
> > when
> > > > do you
> > > > > think you will release a multilingual version of web-erp? And: do
> > you
> > > > need any
> > > > > help? I'd be happy to help in any way.
> > > > > Second: if you're not going to do the multilingual version, can I
> > work
> > > > on it?
> > > > > Can we synch our two different tracks (the improvement of the
> > system
> > > > that
> > > > > maybe you are doing and my translation-multilingual effort)?
> > > > >
> > > > > Please give me an answer on this, since i am strongly sponsoring
> > your
> > > > > product...
> > > > > Best Regards,
> > > > > Luca
> > > > >
> > > > > PS: I am working on the translation of the manual. When finished,
> > I'll
> > > > send it
> > > > > to you.
> > > > >
> > > >
> >
>




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Web-erp-developers mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

Ok, I think the 800x600 should not have Inquiries and Reports wrapping =
underneath the image now which should look better.  At the same time I =
made all the headings look better in positioning.

Please take another look here http://weberp.gocom.ca to confirm when you =
get a chance.

Steve
  ----- Original Message -----=20
  From: Daintrees=20
  To: web...@li...=20
  Sent: Monday, August 02, 2004 4:09 PM
  Subject: Re: [Web-erp-developers] Interface


  Looks better on a 1024x768 than on a 600x800 screen. The inquiries and =
reports heading has to wrap onto two lines.

  The spaced links are less intimidating block of text too.

  Great!


  Notice that the heading/title of the page is missing?

  Phil
    ----- Original Message -----=20
    From: skaill=20
    To: web...@li...=20
    Sent: Tuesday, August 03, 2004 4:40 AM
    Subject: Re: [Web-erp-developers] Interface


    Refined some more at http://weberp.gocom.ca including spacing out =
the action links.

    Steve
      ----- Original Message -----=20
      From: Daintrees=20
      To: web...@li...=20
      Sent: Sunday, August 01, 2004 9:08 PM
      Subject: Re: [Web-erp-developers] Interface


      By menu items I mean the links to action a specific option.
        ----- Original Message -----=20
        From: skaill=20
        To: web...@li...=20
        Sent: Monday, August 02, 2004 11:34 AM
        Subject: Re: [Web-erp-developers] Interface


        Have you looked in the past day or two, Phil?  Some of your =
comments may be before I did a bunch of work.  Hopefully you have some =
time to look again.  No question marks anymore and they were only =
temporary before I was going to create a help graphic.  Anyway, I think =
the way you did with the one Help at the top is good as long as we =
document clearly, possibly in the first online help screen, that the =
help will change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

        The menus would be javascript.  However, I believe when I did =
testing in several browsers on this site I created www.goldenwitch.com =
they worked on all.  Some people with various browsers could try going =
to that site to see if the drop-down menus work perfectly.  It is =
minimal and very standard javascript.  I agree with avoiding javascript, =
java and any other language as much as possible but you can't make =
drop-down menus unless you have code at the client side.  I think ALL =
languages besides PHP, HTML and CSS should be optional in the config or =
elsewhere.

        I still have to get up with the cvs thing.  I have it installed =
but haven't tried it out.  When I do something it's all at once so one =
day soon I'll be doing cvs and will send you.

        I saw the user and database in the newest demo.  Something else =
I noticed though was that the Help gave an error.  Can't remember =
exactly where or why right now though.

        Steve

          ----- Original Message -----=20
          From: Daintrees=20
          To: web...@li...=20
          Sent: Sunday, August 01, 2004 4:15 PM
          Subject: Re: [Web-erp-developers] Interface


          I guess this would be java?
          If it could be made to work in all forms of java then it would =
be a useful addition - I have tried to avoid it so far and have no =
knowlege personally. It is nice not to depend on java for anything. I =
agree it would be good.

          I would like to clean the css if you send me the files.=20

          I like the vertical oreintation of the menus - I think it =
needs some spacing between the menu items - they all merge together.
          As previously mentioned I am not so keen on the preponderance =
of question marks. I think this is probably superseeded following our =
discussion on the help.

          I already added the user and database to the titles - in 2.9


          Phil



            ----- Original Message -----=20
            From: skaill=20
            To: web...@li...=20
            Sent: Monday, August 02, 2004 2:35 AM
            Subject: [Web-erp-developers] Interface


            I've been working with the interface quite a bit now.  For =
those who would like to see what I've done go to http://weberp.gocom.ca. =
 Please make many, many comments good or bad.

            While I've been doing this I fixed some incorrect code and =
cleaned it up, especially the css.  There were several places that had =
commands which weren't actually being used and in fact would lead =
someone to think that what they were seeing should be different.  This =
is typical and I'm no exception but I took the time to do some cleanup.  =
I think it is easier to read and understand now.

            Phil, if you like parts of this refined interface or all of =
it we can get it into the base product.  Let me know.

            I'm seriously thinking about adding code that will do =
drop-down menus and allow a user option to specify whether they see the =
interface displayed now or they see drop-down menus.  With the drop-down =
menus it would allow everything to be accessible all the time with =
little screen space taken up.  It also looks pro.  Plus the fast access =
options become basically irrelevant with drop-down menus.

            Steve

[Web-erp-developers] Fw: Italian Translation of web-erp

[Daintrees <p.d...@pa...>]

Luca,

I am not sure if you have joined the developers list, but I have forw=
areded
this email to them because I would like to run your proposal past the=
 other
interested and knowledgeable folk - hope you dont mind!

We have a table of each script - that was added in 2.9 for the contex=
t
sensitive help (currently not language specific) - each script is giv=
en a
unique id - this may also be helpful for security Steve - the idea of
retrieving just the labels for the script being run is appealing as i=
s
having a user interface for translators that doesnt involve editing f=
iles.
You have some good points. The best point of all - you are prepared t=
o do a
lot of work for the project - most appreciated.

Lets just see if there are any other opinions/pitfalls that the rest =
of the
team see - so we dont trip and fall on this.

Phil

----- Original Message -----=20
=46rom: "ing. Luca Turlon Don=E0" <luc...@pd...>
To: "Phil Daintree" <p.d...@pa...>
Sent: Tuesday, August 03, 2004 12:11 AM
Subject: Re: Italian Translation of web-erp


> Hi Phil.
> I've been reading thru your mail several times before answering, ca=
use
wanted
> to be sure to understand every single issue ou pointed out.
>
> The main consideration that comes out is that your approach is very
similar to
> mine, i.e.:
> -You are proposing a function call, I am proposing to use an array =
with a
> literal index.
> -You are proposing several files with the translation, i am proposi=
ng
several
> groups of rows in a table.
>
> Firts let me explain one thing: my idea consists in loading an arra=
y from
the
> db, i.e.: in the beginning of every page I make a bulk load of all =
the
labels
> in the language that has to be shown. So we do not have a full read=
 cycle
> (connect-query-parse the query, disconnect) on the db for every sin=
gle
label
> in the page. We read everything at the beginning, load it in the la=
ng
array
> and then use the lang array. This should address the second concern=
 that
you
> put in your email. There is another thing: if we add a column on th=
e db
table,
> containing the script (or an unique code which identifies the scrip=
t) that
is
> going to be rendered we can achieve two more thing: first we can lo=
ad just
the
> labels used in that script, reducing the size of the array. Secondl=
y we
will
> have a documentation of what is shown in every page.
>
> Regarding the other concern, i.e. the smallness of 30 chars for a l=
abel
> identifier, I believe that i could enlarge that column to a wider s=
tring:
i do
> not see any problem on this.
>
> The last thing you say, that is the code should be easy understanda=
ble.
Maybe
> you're right in considering the code easier to read having a full e=
nglish
> label, but I think that a label identifier with some comment could =
do the
> same. In this way you could avoid the problem you mentioned about c=
hanges
in
> the english labels.
>
> Please now let me tell some other things about the "function" appro=
ach:
> a) there is no other way than creating a php script to translate th=
e
> application. With the db approach I could create a page to let any =
kind of
> user (not only a PHP programmer) manage the translation
> b) it can become tough managing any new version of the system: with=
 the db
you
> can query and see how many entries you have for each language, and =
you can
> easily identify which labels has to be translated. With the include=
d file
> approach you have to work on the files, hoping that every file is w=
ritten
with
> exactly the same approach.
> c) Since you must delegate people to translate (unless you know at =
least
15
> languages) you can loose control on the code: what if a russian sen=
ds you
an
> email saying that the system not working, just because the russian
translator
> forgot a ";" in his code? With the db approach the worst thing that=
 could
> happen is a wrong translation or something written in English, but =
not
> something that halts the system.
> d) With the db you have a sort of documentation, which can help in
creating
> help files...
> e) it is at any time possible to automatically generate any languag=
e
script,
> i.e a language/italiano.php can be generated from the db and we can=
 switch
to
> your "function" approach.
> f) ther is another thing regarding the usage of the entire english =
label
as a
> parameter: imagine if you forget to put the function call. With the=
 label
> identifier you immediately see that there is something difficult to=
 read
on
> the page. With the full english label you may even not notice the e=
rror.
>
>
> Finally: I do believe that the language variable should be kept, in=
 the
> future, in the session of the user, having each user working with h=
is/her
own
> language. For now I am just using a default language, but in the fu=
ture it
can
> be changed.
>
> One very last thing: I have to work on it, 'cause these friends of =
mine
needs
> it, and I will work on the application making it multilanguage. I w=
ill go
thru
> the entire application, populating the db tables and changing the  =
scripts
> where needed. After I will finish my job, I believe by the end of
september, I
> am going to send you the result of my job: thus you'll get a finish=
ed a
work,
> and you'd be not worried by having something not finished. The only=
 thing
is
> to understand what has changed from noew (or better from the 2.9 re=
lease
of
> the system) till the end of september.
>
> Luca
>
> Scrive Phil Daintree <p.d...@pa...>:
>
> > Hi Luca,
> >
> > There has been quite a bit of a discussion about multi-language -=
 there
> > are a lot of issues. Maybe I scare too easily, but it seems like =
a
> > massive undertaking :-O
> >
> > Thanks so much for considering what is really quite a sizable pro=
ject
> > here. The other fear factor in taking this sort of thing on is if=
 we
> > start it I am the muggins that has a stuffed system if we can't f=
inish
> > it. It sure would be great to make web-erp multi-language.
> >
> > I see the way you are heading with what you started .... my over-=
riding
> > and BIG worry in going to multi-language is that the code might b=
ecome
> > more difficult to make sense of (of course it being in English mu=
st be
> > quite a snag for those who use another language anyway). Under th=
e
> > scenario you are proposing we would, I guess have a varchar(30)
> > description for the label that would be substituted by the TEXT f=
ield.
> > There a couple of reasons why I'm not that keen on this approach:
> >
> > 1. 30 characters isn't much to describe the text variable. The fu=
ll
> > context that the label provides I think significantly improves th=
e
> > ability to understand code.
> > 2. If this requires a query for every label then this could be qu=
ite an
> > overhead on the db and a potential delay for the user. (all users=
).
> >
> > Of the approaches discussed in the developers list - there is an =
archive
> > of this http://sourceforge.net/mailarchive/forum.php?forum_id=
=3D34088
> >
> > I prefer Steve Kaill's approach and the approach used in open-acc=
ounting
> > ie enclosing the the full label in a function call eg.
> >
> > echo language("This is how I rekon we should do multi-language so=
 the
> > code remains relatively easy to read");
> >
> > the language function returns the language string required by the=
 user.
> >
> > We hold a $_SESSION['language'] variable which is stored in the
> > www_users table and retreived at the time of login.
> >
> > This language variable would be the same name as the file to incl=
ude
> > under a new languages directory.
> >
> > The function language would be in this include directory.
> >
> > The function language then takes the text of the english label as=
 a
> > parameter - the $SESSION['language'] is defined as global inside =
this
> > function and returns the the language string appropriate - if the=
re is
> > no match for the string parameter passed then the parameter ie th=
e
> > english label is returned.
> >
> > The english language function in languages/english.php would just=
 return
> > the parameter itself.
> >
> > I have not gone down the track of considering if the label substi=
tution
> > is done using an array or what .... I would probably take a look =
at
> > open-accounting logic.
> >
> > This approach does retain a critical requirement for webERP ie th=
at of
> > easily understandable code.
> >
> > All approaches have their down side -
> >
> > 1. This puts the overhead on the web-server/ php interpreter. How=
ever,
> > this is pretty fast.However,potentially significant memory is req=
uired -
> > for what I have tried desperately to be minimalist in terms of re=
sources
> > required to run it.
> >
> > 2. Anyone changing the english labels will stuff up the translati=
on file
> > ie the include file of strings in english with the equivalent lan=
guage
> > string!
> >
> > Do you see any other snags with this approach Luca?
> > Could you consider a slightly different approach?
> >
> > Phil
> >
> >
> > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=3D?ISO-8859-1?Q?lon_Do=
n=3DE0?=3D
> > wrote:
> > > Hello Phil,
> > > I've started to work on it.
> > > Here is how I want to address the issue.
> > > First I am going to create a table containing all the labels
> > >
> > > CREATE TABLE `languages` (
> > >   `id` bigint(20) NOT NULL auto_increment,
> > >   `LANGID` varchar(15) NOT NULL default '',
> > >   `TEXTID` varchar(30) NOT NULL default '',
> > >   `TEXT` varchar(255) NOT NULL default '',
> > >   UNIQUE KEY `id` (`id`)
> > > ) TYPE=3DInnoDB COMMENT=3D'Table containing labels to be showed=
 on the
> > pages';
> > >
> > > (I don't think InnoDB is necessary for this table, since it is =
only
> > read by
> > > normal users, and loaded by installer: i kept that type only fo=
r
> > compatibility
> > > with your design).
> > >
> > > TEXTID is a code that identifies a specific label in very page.=
 With
> > some work
> > > we can undertsand if the same label is going to be used on diff=
rent
> > pages.
> > > TEXT is the text that is going to appear on the browser.
> > >
> > > On the config.php file I've inserted another variable:
> > > $DefaultLanguage=3D"ITALIANO"; //of course you can put ENGLISH
> > >
> > > In session.inc i've inserted this line
> > >     include ("language.php");
> > > just after
> > >     include("includes/ConnectDB.inc");
> > >
> > > As you can see in the attachment, language.php loads an array n=
amed
> > $lang with
> > > the contents of the table "languages".
> > > By default it loads the $DefaultLanguage, but if the variable i=
s not
> > defined it
> > > loads the English table.
> > >
> > > Then I simply substitute all the labels around the php and html=
 code
> > with the
> > > corresponding entry in the $lang array.
> > > As an example you can see in the attached login.php file the fo=
llowing
> > lines: 9,
> > > 53, 57, 66.
> > >
> > > Having the labels in a db table can lead to another enhancement=
: every
> > user can
> > > choose his/her own language. This could be useful for companies=
 having
> > clients
> > > spreaded around various countries....
> > >
> > > What do you think about?
> > > Can we arrange my small improvement with the future developemen=
t you
> > are making
> > > in web-erp?
> > >
> > > Luca
> > >
> > >
> > > Scrive Phil Daintree <p.d...@pa...>:
> > >
> > > > There has been some discussion about multi-language recently =
on the
> > > > list.
> > > >
> > > > I am prepared to maintain a rigorous log of changes to script=
s.
> > Perhaps
> > > > I could produce a diff file for all changes on each release b=
ut you
> > > > would have to apply these changes to the italian version. I h=
ave had
> > a
> > > > similar request from a spanish speaking person.
> > > >
> > > > An Italian version would be good.
> > > >
> > > > web-erp is not ideally suited to multi-language as you point =
out
> > since
> > > > all labels, print and echo statements would need to be modifi=
ed and
> > > > changes in the core scripts would need to be applied to each
> > language's
> > > > scripts manually.
> > > >
> > > > Phil
> > > >
> > > >
> > > > On Thu, 2004-07-29 at 17:28, ing. Luca
> > Tur=3D?ISO-8859-1?Q?lon_Don=3DE0?=3D
> > > > wrote:
> > > > > Dear Phil,
> > > > > a couple of friends, who ar starting up a new fashion compa=
ny here
> > in
> > > > italy,
> > > > > are very interested in using the application you developed.
> > > > >
> > > > > Since they're not very acquainted with the english language=
 and
> > > > jargon, i need
> > > > > to translate the application for them.
> > > > >
> > > > > I have various ways to do this: one is to simply browse the=
 code
> > and
> > > > change
> > > > > all the labels into italian. Doing so, i am very concerned =
about
> > > > everytime you
> > > > > give a new release: at that time I have to check every chan=
ge in
> > every
> > > > single
> > > > > file.
> > > > > The other one is to modify the code in order to have a sepa=
rate
> > place
> > > > in which
> > > > > labels and all the language-dependent stuff are stored. Thi=
s can
> > be a
> > > > DB table
> > > > > or a file... i still don't know.
> > > > > Before starting this, i need to know a couple of things:
> > > > > First: are you going to do what I would like to do? In this=
 case
> > when
> > > > do you
> > > > > think you will release a multilingual version of web-erp? A=
nd: do
> > you
> > > > need any
> > > > > help? I'd be happy to help in any way.
> > > > > Second: if you're not going to do the multilingual version,=
 can I
> > work
> > > > on it?
> > > > > Can we synch our two different tracks (the improvement of t=
he
> > system
> > > > that
> > > > > maybe you are doing and my translation-multilingual effort)=
?
> > > > >
> > > > > Please give me an answer on this, since i am strongly spons=
oring
> > your
> > > > > product...
> > > > > Best Regards,
> > > > > Luca
> > > > >
> > > > > PS: I am working on the translation of the manual. When fin=
ished,
> > I'll
> > > > send it
> > > > > to you.
> > > > >
> > > >
> >
>

Re: [Web-erp-developers] Interface

[Daintrees <p.d...@pa...>]

Looks better on a 1024x768 than on a 600x800 screen. The inquiries and =
reports heading has to wrap onto two lines.

The spaced links are less intimidating block of text too.

Great!


Notice that the heading/title of the page is missing?

Phil
  ----- Original Message -----=20
  From: skaill=20
  To: web...@li...=20
  Sent: Tuesday, August 03, 2004 4:40 AM
  Subject: Re: [Web-erp-developers] Interface


  Refined some more at http://weberp.gocom.ca including spacing out the =
action links.

  Steve
    ----- Original Message -----=20
    From: Daintrees=20
    To: web...@li...=20
    Sent: Sunday, August 01, 2004 9:08 PM
    Subject: Re: [Web-erp-developers] Interface


    By menu items I mean the links to action a specific option.
      ----- Original Message -----=20
      From: skaill=20
      To: web...@li...=20
      Sent: Monday, August 02, 2004 11:34 AM
      Subject: Re: [Web-erp-developers] Interface


      Have you looked in the past day or two, Phil?  Some of your =
comments may be before I did a bunch of work.  Hopefully you have some =
time to look again.  No question marks anymore and they were only =
temporary before I was going to create a help graphic.  Anyway, I think =
the way you did with the one Help at the top is good as long as we =
document clearly, possibly in the first online help screen, that the =
help will change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

      The menus would be javascript.  However, I believe when I did =
testing in several browsers on this site I created www.goldenwitch.com =
they worked on all.  Some people with various browsers could try going =
to that site to see if the drop-down menus work perfectly.  It is =
minimal and very standard javascript.  I agree with avoiding javascript, =
java and any other language as much as possible but you can't make =
drop-down menus unless you have code at the client side.  I think ALL =
languages besides PHP, HTML and CSS should be optional in the config or =
elsewhere.

      I still have to get up with the cvs thing.  I have it installed =
but haven't tried it out.  When I do something it's all at once so one =
day soon I'll be doing cvs and will send you.

      I saw the user and database in the newest demo.  Something else I =
noticed though was that the Help gave an error.  Can't remember exactly =
where or why right now though.

      Steve

        ----- Original Message -----=20
        From: Daintrees=20
        To: web...@li...=20
        Sent: Sunday, August 01, 2004 4:15 PM
        Subject: Re: [Web-erp-developers] Interface


        I guess this would be java?
        If it could be made to work in all forms of java then it would =
be a useful addition - I have tried to avoid it so far and have no =
knowlege personally. It is nice not to depend on java for anything. I =
agree it would be good.

        I would like to clean the css if you send me the files.=20

        I like the vertical oreintation of the menus - I think it needs =
some spacing between the menu items - they all merge together.
        As previously mentioned I am not so keen on the preponderance of =
question marks. I think this is probably superseeded following our =
discussion on the help.

        I already added the user and database to the titles - in 2.9


        Phil



          ----- Original Message -----=20
          From: skaill=20
          To: web...@li...=20
          Sent: Monday, August 02, 2004 2:35 AM
          Subject: [Web-erp-developers] Interface


          I've been working with the interface quite a bit now.  For =
those who would like to see what I've done go to http://weberp.gocom.ca. =
 Please make many, many comments good or bad.

          While I've been doing this I fixed some incorrect code and =
cleaned it up, especially the css.  There were several places that had =
commands which weren't actually being used and in fact would lead =
someone to think that what they were seeing should be different.  This =
is typical and I'm no exception but I took the time to do some cleanup.  =
I think it is easier to read and understand now.

          Phil, if you like parts of this refined interface or all of it =
we can get it into the base product.  Let me know.

          I'm seriously thinking about adding code that will do =
drop-down menus and allow a user option to specify whether they see the =
interface displayed now or they see drop-down menus.  With the drop-down =
menus it would allow everything to be accessible all the time with =
little screen space taken up.  It also looks pro.  Plus the fast access =
options become basically irrelevant with drop-down menus.

          Steve

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

At first I don't think I understood your point about Setup always appearing.
Possibly setup could go above in the quick menu.  Logout could go back up
there too.  I moved them down as I pondered whether the quick access was a
good thing.  You easily convinced me that it was, however, I'm still
pondering it being more of a toolbar thing.  One thing for sure, if Setup
needs to sometimes be displayed on the Menu for admins then it may as well
be displayed all the time because there must always be room set aside for
it.  Even though it appears all the time it can still be distinguished as
being inaccessible by graying out, etc.  I actually have Admin (setup
renamed on mine) grayed right now when demo logs in but not when Admin logs
in.

I'm also not sure that Main need to be an option at all.  The fact that the
system comes up in Main is a good thing I believe.  The reason is that it's
an introduction as well as a possible "advertising" area.  With it, the user
does not feel that they have been blasted into the middle of the system
right away.  However, it's not really necessary for the user to be able to
re-access Main again within the session.  Possibly, therefore, the Main menu
option could be removed.

Steve

----- Original Message ----- 
From: "Phil Daintree" <p.d...@pa...>
To: <web...@li...>
Sent: Monday, August 02, 2004 2:52 PM
Subject: Re: [Web-erp-developers] Interface


> On Sun, 2004-08-01 at 15:35, skaill wrote:
> > I've been working with the interface quite a bit now.  For those who
> > would like to see what I've done go to http://weberp.gocom.ca.  Please
> > make many, many comments good or bad.
> >
> Steve,
>
> I didn't understand what "main" was for - looks like we could lose this
> happily?
>
> Having setup on the main menu by default could be inviting trouble? I
> prefer setup options out of the way and not in your face as it were - so
> folks arent tempted to have a look! This would leave more room for
> longer more descriptive links that dont straddle several lines. It would
> be nice to space the links somehow.
>
> Another 2c
>
> Phil
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

There's technically a quick menu and a main menu.  In my view though I don't
think of the quick menu as such.  It is part of the header and I view it
more as akin to a toolbar of options.  In fact I have some further ideas
about that toolbar concept but not worth discussing until I think and play
around some more.  So, viewing the fast access/quick menu options as a sort
of toolbar then there is one menu.  Besides, the quick menu appears all the
time so the Menu option can only mean the "main" menu.

To me, the various setup options within webERP fall into two categories:
support tables and setup/admin.  For the support tables I'm thinking they
belong more appropriately in their respective section.

My take on where setup options should be located runs parallel to the
following ideas.  First, I think that knowing there is Sales Type
Maintenance leads to better understanding by the users.  They would know
that if they don't see a Sales Type that should be there then it can be
added to Sales Types by someone with access.  Yes, maybe they should not
have access to it and those options inaccessible to them should be readily
recognizable as off limits.  Usually this means graying them out, etc.
Notice if you bring up Word and click the drop-down menus there are options
available and other options inaccessible.  It is based on context with the
grayed options being inaccessible.  The context, in the setup case, is the
user.  The second idea is about having things where they have the most
relevance.  e.g. Sales setup with Sales options.    Also, where they would
best be accessed by someone other than the administrator so that strictly
administration options are within the administrator area.  These would be
options that no one else should see and need not understand exist such as
backup/restore, user maintenance, etc.  Possibly some of the config options
should be in the admin section as well but that's another topic!

There still may be good points about keeping the setup all in the one area,
however, these are my viewpoints about it so far.  It's something to think
about.  I do know that at least some mid-sized erp systems do organize the
setup options within the areas as I have done.  Possibly others have them in
a separate area...

Steve

----- Original Message ----- 
From: "Phil Daintree" <p.d...@pa...>
To: <web...@li...>
Sent: Monday, August 02, 2004 2:52 PM
Subject: Re: [Web-erp-developers] Interface


> On Sun, 2004-08-01 at 15:35, skaill wrote:
> > I've been working with the interface quite a bit now.  For those who
> > would like to see what I've done go to http://weberp.gocom.ca.  Please
> > make many, many comments good or bad.
> >
> Steve,
>
> I didn't understand what "main" was for - looks like we could lose this
> happily?
>
> Having setup on the main menu by default could be inviting trouble? I
> prefer setup options out of the way and not in your face as it were - so
> folks arent tempted to have a look! This would leave more room for
> longer more descriptive links that dont straddle several lines. It would
> be nice to space the links somehow.
>
> Another 2c
>
> Phil
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

Working the way I am for right now is due to my lack of knowledge of cvs
from the start.  What I will do soon is get up to speed with cvs and then
compare your 2.8 to my 2.8 modified with my compare tools.  I will then move
all of my changes into a newly checked out cvs 2.9.  Afterward I can send
you my modified 2.9, the 2.9 diff or whatever I'm supposed to do.

I tried the demo help again and cannot find the issue anywhere.  I'm
confused about whether you agreed that it would be good to cut various
sections of the manual and put them into the online help.  It seemed like
the best and quickest way to get some help in there everywhere.  If so, it's
what I plan on doing soon on my copy.

Could it be a setting in Konqueror that causes the drop-down menu not to
work?  Can you take a look at http://www.infocentral.org/demo/Default.php
and let me know if the menus there work with those browsers?  The javascript
code for them is somewhat different and possibly better.  For sure normal
menus will be default.  User must switch their setting to activate drop-down
menus

Steve

----- Original Message ----- 
From: "Phil Daintree" <p.d...@pa...>
To: <web...@li...>
Sent: Monday, August 02, 2004 2:36 PM
Subject: Re: [Web-erp-developers] Interface


> On Mon, 2004-08-02 at 00:34, skaill wrote:
> > Have you looked in the past day or two, Phil?  Some of your comments
> > may be before I did a bunch of work.  Hopefully you have some time to
> > look again.  No question marks anymore and they were only temporary
> > before I was going to create a help graphic.  Anyway, I think the way
> > you did with the one Help at the top is good as long as we document
> > clearly, possibly in the first online help screen, that the help will
> > change contextually.  Possibly by the menu items you mean the
> > menu_group_items or do you mean the main_menu?
>
> Looked again - yes it looks really good now! Keen to incorporate this. I
> notice you havent got the Help link yet. Interested to find out the
> difficulty you had with the help. I think the main difficulty will be in
> populating the help table with useful data. It would be nice if the text
> in the Help table was html - I put some stuff in for the main menu just
> to test it.
>
> >
> > The menus would be javascript.  However, I believe when I did testing
> > in several browsers on this site I created www.goldenwitch.com they
> > worked on all.  Some people with various browsers could try going to
> > that site to see if the drop-down menus work perfectly.  It is minimal
> > and very standard javascript.  I agree with avoiding javascript, java
> > and any other language as much as possible but you can't make
> > drop-down menus unless you have code at the client side.  I think ALL
> > languages besides PHP, HTML and CSS should be optional in the config
> > or elsewhere.
> >
>
> Firefox works fine with the drop down menus on that site but Konqueror
> cant actually get to the menu - eg the "Fine Tackle" brings down the
> choices for Rods, Reels etc but I cant get to the links without moving
> over "Rod Making" - so the options come up with Tools etc and I cant
> activate any of the links for Fine Tackle.
>
> I think it would be good to have some interactivity like this on the
> main menu in particular but we need a back stop option that always
> works.
>
> Phil
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

Refined some more at http://weberp.gocom.ca including spacing out the =
action links.

Steve
  ----- Original Message -----=20
  From: Daintrees=20
  To: web...@li...=20
  Sent: Sunday, August 01, 2004 9:08 PM
  Subject: Re: [Web-erp-developers] Interface


  By menu items I mean the links to action a specific option.
    ----- Original Message -----=20
    From: skaill=20
    To: web...@li...=20
    Sent: Monday, August 02, 2004 11:34 AM
    Subject: Re: [Web-erp-developers] Interface


    Have you looked in the past day or two, Phil?  Some of your comments =
may be before I did a bunch of work.  Hopefully you have some time to =
look again.  No question marks anymore and they were only temporary =
before I was going to create a help graphic.  Anyway, I think the way =
you did with the one Help at the top is good as long as we document =
clearly, possibly in the first online help screen, that the help will =
change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

    The menus would be javascript.  However, I believe when I did =
testing in several browsers on this site I created www.goldenwitch.com =
they worked on all.  Some people with various browsers could try going =
to that site to see if the drop-down menus work perfectly.  It is =
minimal and very standard javascript.  I agree with avoiding javascript, =
java and any other language as much as possible but you can't make =
drop-down menus unless you have code at the client side.  I think ALL =
languages besides PHP, HTML and CSS should be optional in the config or =
elsewhere.

    I still have to get up with the cvs thing.  I have it installed but =
haven't tried it out.  When I do something it's all at once so one day =
soon I'll be doing cvs and will send you.

    I saw the user and database in the newest demo.  Something else I =
noticed though was that the Help gave an error.  Can't remember exactly =
where or why right now though.

    Steve

      ----- Original Message -----=20
      From: Daintrees=20
      To: web...@li...=20
      Sent: Sunday, August 01, 2004 4:15 PM
      Subject: Re: [Web-erp-developers] Interface


      I guess this would be java?
      If it could be made to work in all forms of java then it would be =
a useful addition - I have tried to avoid it so far and have no knowlege =
personally. It is nice not to depend on java for anything. I agree it =
would be good.

      I would like to clean the css if you send me the files.=20

      I like the vertical oreintation of the menus - I think it needs =
some spacing between the menu items - they all merge together.
      As previously mentioned I am not so keen on the preponderance of =
question marks. I think this is probably superseeded following our =
discussion on the help.

      I already added the user and database to the titles - in 2.9


      Phil



        ----- Original Message -----=20
        From: skaill=20
        To: web...@li...=20
        Sent: Monday, August 02, 2004 2:35 AM
        Subject: [Web-erp-developers] Interface


        I've been working with the interface quite a bit now.  For those =
who would like to see what I've done go to http://weberp.gocom.ca.  =
Please make many, many comments good or bad.

        While I've been doing this I fixed some incorrect code and =
cleaned it up, especially the css.  There were several places that had =
commands which weren't actually being used and in fact would lead =
someone to think that what they were seeing should be different.  This =
is typical and I'm no exception but I took the time to do some cleanup.  =
I think it is easier to read and understand now.

        Phil, if you like parts of this refined interface or all of it =
we can get it into the base product.  Let me know.

        I'm seriously thinking about adding code that will do drop-down =
menus and allow a user option to specify whether they see the interface =
displayed now or they see drop-down menus.  With the drop-down menus it =
would allow everything to be accessible all the time with little screen =
space taken up.  It also looks pro.  Plus the fast access options become =
basically irrelevant with drop-down menus.

        Steve

Re: [Web-erp-developers] Interface

[Phil D. <p.d...@pa...>]

On Sun, 2004-08-01 at 15:35, skaill wrote:
> I've been working with the interface quite a bit now.  For those who
> would like to see what I've done go to http://weberp.gocom.ca.  Please
> make many, many comments good or bad.
>  
Steve,

I didn't understand what "main" was for - looks like we could lose this
happily?

Having setup on the main menu by default could be inviting trouble? I
prefer setup options out of the way and not in your face as it were - so
folks arent tempted to have a look! This would leave more room for
longer more descriptive links that dont straddle several lines. It would
be nice to space the links somehow.

Another 2c

Phil

Re: [Web-erp-developers] Interface

[Phil D. <p.d...@pa...>]

On Mon, 2004-08-02 at 00:34, skaill wrote:
> Have you looked in the past day or two, Phil?  Some of your comments
> may be before I did a bunch of work.  Hopefully you have some time to
> look again.  No question marks anymore and they were only temporary
> before I was going to create a help graphic.  Anyway, I think the way
> you did with the one Help at the top is good as long as we document
> clearly, possibly in the first online help screen, that the help will
> change contextually.  Possibly by the menu items you mean the
> menu_group_items or do you mean the main_menu?

Looked again - yes it looks really good now! Keen to incorporate this. I
notice you havent got the Help link yet. Interested to find out the
difficulty you had with the help. I think the main difficulty will be in
populating the help table with useful data. It would be nice if the text
in the Help table was html - I put some stuff in for the main menu just
to test it.

>  
> The menus would be javascript.  However, I believe when I did testing
> in several browsers on this site I created www.goldenwitch.com they
> worked on all.  Some people with various browsers could try going to
> that site to see if the drop-down menus work perfectly.  It is minimal
> and very standard javascript.  I agree with avoiding javascript, java
> and any other language as much as possible but you can't make
> drop-down menus unless you have code at the client side.  I think ALL
> languages besides PHP, HTML and CSS should be optional in the config
> or elsewhere.
>  

Firefox works fine with the drop down menus on that site but Konqueror
cant actually get to the menu - eg the "Fine Tackle" brings down the
choices for Rods, Reels etc but I cant get to the links without moving
over "Rod Making" - so the options come up with Tools etc and I cant
activate any of the links for Fine Tackle.

I think it would be good to have some interactivity like this on the
main menu in particular but we need a back stop option that always
works.

Phil

Re: Fw: [Web-erp-developers] Warehouse Bin Locations

[Danie B. <br...@na...>]

Thanks Steve I Received it.

Quoting skaill <sk...@ro...>:

> Ok, trying this a third time.  First time it came back saying they don't let
> files over 44k through.  Second time it said they block zip files.  So, I
> converted it to a text file.  A bit messy but if you bring into a word pro
> it should be better.
> 
> Steve
> 
> ----- Original Message ----- 
> From: "skaill" <sk...@ro...>
> To: <web...@li...>
> Sent: Saturday, July 31, 2004 7:41 AM
> Subject: Re: [Web-erp-developers] Warehouse Bin Locations
> 
> 
> > Hi Danie,
> >
> > Here is a summary specification that comes from the various documents and
> > knowledge I've collected over the years.  It's far from ideal as I just
> > created it since I can't give you any proprietary documents I have from
> > other companies!
> >
> > Down the road we will be looking thoroughly into the tax functionality of
> > webERP.  If everything in this specification is not covered we will
> probably
> > be enhancing webERP to cover it.
> >
> > Keep in mind that as long as the user can manually enter/modify various
> > taxes for different jurisdictions on the invoice then at least they can
> get
> > by even if somewhat painfully.
> >
> > Feel free to discuss more about tax with me anytime.
> >
> > Steve
> >
> > ----- Original Message ----- 
> > From: "Danie Brink" <br...@na...>
> > To: <web...@li...>
> > Sent: Saturday, July 31, 2004 4:48 AM
> > Subject: Re: [Web-erp-developers] Warehouse Bin Locations
> >
> >
> > > Quoting skaill <sk...@ro...>:
> > >
> > > Hi Steve,
> > >
> > > Please go ahaid and send some specs to me so I can have a look. At the
> > very
> > > least I want to make it possible to incorporate multiple taxes on an
> > Invoice.
> > > Well, actualy I still need to do two more screens and convert the Stock
> > master
> > > table and a couple of others to reference the new structure.
> > >
> > > Kind Regards.
> > > Danie
> > >
> > > > Hi Danie,
> > > >
> > > > I may be able to help in some ways with the tax changes.  I spec'd and
> > > > rewrote the entire tax functionality for one of the leading world-wide
> 
> > > > mid-range erp softwares.  It's one of my specialties ;)
> > > >
> > > > Steve
> > > >
> > > > ----- Original Message ----- 
> > > > From: "Danie Brink" <br...@na...>
> > > > To: <web...@li...>
> > > > Sent: Friday, July 30, 2004 3:42 AM
> > > > Subject: Re: [Web-erp-developers] Warehouse Bin Locations
> > > >
> > > >
> > > > > Hi Phil
> > > > >
> > > > > Danie Here,
> > > > >
> > > > > We have managed to get a small contract for web-erp and we have to
> > build
> > > > in
> > > > > proper manufacturing and job control as well as job costing. We are
> > three
> > > > > people whom have worked on this type of thing in the past, and we
> must
> > > > > implement it. What I am realy asking is not to energize yourself to
> > fast
> > > > we
> > > > > have to do this in the next few months, maybe you can once we are
> done
> > > > have a
> > > > > look at it. Also I have to change the Tax system to accomodate the
> > client
> > > > which
> > > > > I will also contribute back. It basicaly involve the seperation of
> Tax
> > > > > Authority and Tax Types( where Gl Accounts and rates are specified)
> > and
> > > > then
> > > > > the creation of a Stock Tax Category Table which replace the levels
> > and
> > > > will be
> > > > > foreign key linked to Stock master Tax Level ( Replacing Tax Level )
> > and
> > > > all
> > > > > other places Tax Level And Tax Authotity are refferenced. The Tax
> > Rates
> > > > which
> > > > > usualy is an loose assosiation will now be a fixed assosiation
> between
> > Tax
> > > > > authority, Dispatch Tax Auth, Tax Type and Tax Category. This also
> > allow
> > > > us to
> > > > > customize the reports to use the TaxType Report Field for the lookup
> > of
> > > > the
> > > > > actual display name on invoice and also the totaling of different
> > taxes of
> > > > > items on invoice and display thereof. Also we will be trying to fit
> > the
> > > > > postgres conversion into the time alotted as well.
> > > > >
> > > > > Also one we have finished with this client I am trying to put
> together
> > > > some
> > > > > stuff for an exibition booth. I have a Stock Exchange software and
> SMS
> > > > software
> > > > > (windows only, old, but good) which we will be giving away free to
> > garner
> > > > some
> > > > > interest, It will probably be an indisutrial technology exibition.
> > > > >
> > > > > Kind Regards
> > > > > Danie Brink
> > > > >
> > > > > Quoting Phil Daintree <p.d...@pa...>:
> > > > >
> > > > > > Nope we don't have warehousing management at all.
> > > > > >
> > > > > > Really in most situations it is possible to have the same item in
> > > > > > several different bins. So a single bin location for each item in
> > the
> > > > > > stocks master record doesnt really cut it.
> > > > > >
> > > > > > To do the job properly we are talking about another table for
> bins -
> > a
> > > > > > record for each available bin perhaps that gets updated with the
> > > > > > quantity of a part. This then gives us the option to suggest a
> > picking
> > > > > > run for the dispatch team - but a whole heap more input ....
> ideally
> > by
> > > > > > barcode at the time of picking - scanning serial numbers/batch
> > > > > > references as necessary too. This barcode data could then form the
> > basis
> > > > > > of an automated order confirmation/invoicing run. This would be an
> > > > > > interesting project BUT I must now focus on manufacturing once I
> get
> > > > > > re-energised for another development phase!
> > > > > >
> > > > > > Phil
> > > > > >
> > > > > >
> > > > > > On Wed, 2004-07-28 at 16:32, Chris Bice wrote:
> > > > > > > I know we have a location for inventory but do we have "BIN"
> > > > > > > locations.  Like a BIN in the warehouse???  If not, I will plan
> on
> > > > > > > adding the functionality for that.
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Chris
> > > > > >
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------
> > > > > > This SF.Net email is sponsored by BEA Weblogic Workshop
> > > > > > FREE Java Enterprise J2EE developer tools!
> > > > > > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > > > > > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > > > > > _______________________________________________
> > > > > > Web-erp-developers mailing list
> > > > > > Web...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by OSTG. Have you noticed the changes
> > on
> > > > > Linux.com, ITManagersJournal and NewsForge in the past few weeks?
> Now,
> > > > > one more big change to announce. We are now OSTG- Open Source
> > Technology
> > > > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > > > _______________________________________________
> > > > > Web-erp-developers mailing list
> > > > > Web...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by OSTG. Have you noticed the changes
> on
> > > > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > > > one more big change to announce. We are now OSTG- Open Source
> Technology
> > > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > > _______________________________________________
> > > > Web-erp-developers mailing list
> > > > Web...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> > > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > > one more big change to announce. We are now OSTG- Open Source Technology
> > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > _______________________________________________
> > > Web-erp-developers mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> 

Re: [Web-erp-developers] Interface

[Daintrees <p.d...@pa...>]

By menu items I mean the links to action a specific option.
  ----- Original Message -----=20
  From: skaill=20
  To: web...@li...=20
  Sent: Monday, August 02, 2004 11:34 AM
  Subject: Re: [Web-erp-developers] Interface


  Have you looked in the past day or two, Phil?  Some of your comments =
may be before I did a bunch of work.  Hopefully you have some time to =
look again.  No question marks anymore and they were only temporary =
before I was going to create a help graphic.  Anyway, I think the way =
you did with the one Help at the top is good as long as we document =
clearly, possibly in the first online help screen, that the help will =
change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

  The menus would be javascript.  However, I believe when I did testing =
in several browsers on this site I created www.goldenwitch.com they =
worked on all.  Some people with various browsers could try going to =
that site to see if the drop-down menus work perfectly.  It is minimal =
and very standard javascript.  I agree with avoiding javascript, java =
and any other language as much as possible but you can't make drop-down =
menus unless you have code at the client side.  I think ALL languages =
besides PHP, HTML and CSS should be optional in the config or elsewhere.

  I still have to get up with the cvs thing.  I have it installed but =
haven't tried it out.  When I do something it's all at once so one day =
soon I'll be doing cvs and will send you.

  I saw the user and database in the newest demo.  Something else I =
noticed though was that the Help gave an error.  Can't remember exactly =
where or why right now though.

  Steve

    ----- Original Message -----=20
    From: Daintrees=20
    To: web...@li...=20
    Sent: Sunday, August 01, 2004 4:15 PM
    Subject: Re: [Web-erp-developers] Interface


    I guess this would be java?
    If it could be made to work in all forms of java then it would be a =
useful addition - I have tried to avoid it so far and have no knowlege =
personally. It is nice not to depend on java for anything. I agree it =
would be good.

    I would like to clean the css if you send me the files.=20

    I like the vertical oreintation of the menus - I think it needs some =
spacing between the menu items - they all merge together.
    As previously mentioned I am not so keen on the preponderance of =
question marks. I think this is probably superseeded following our =
discussion on the help.

    I already added the user and database to the titles - in 2.9


    Phil



      ----- Original Message -----=20
      From: skaill=20
      To: web...@li...=20
      Sent: Monday, August 02, 2004 2:35 AM
      Subject: [Web-erp-developers] Interface


      I've been working with the interface quite a bit now.  For those =
who would like to see what I've done go to http://weberp.gocom.ca.  =
Please make many, many comments good or bad.

      While I've been doing this I fixed some incorrect code and cleaned =
it up, especially the css.  There were several places that had commands =
which weren't actually being used and in fact would lead someone to =
think that what they were seeing should be different.  This is typical =
and I'm no exception but I took the time to do some cleanup.  I think it =
is easier to read and understand now.

      Phil, if you like parts of this refined interface or all of it we =
can get it into the base product.  Let me know.

      I'm seriously thinking about adding code that will do drop-down =
menus and allow a user option to specify whether they see the interface =
displayed now or they see drop-down menus.  With the drop-down menus it =
would allow everything to be accessible all the time with little screen =
space taken up.  It also looks pro.  Plus the fast access options become =
basically irrelevant with drop-down menus.

      Steve

Re: [Web-erp-developers] Interface

[Daintrees <p.d...@pa...>]

I looked for the first time on the weekend when you gave us the URL.

Phil
  ----- Original Message -----=20
  From: skaill=20
  To: web...@li...=20
  Sent: Monday, August 02, 2004 11:34 AM
  Subject: Re: [Web-erp-developers] Interface


  Have you looked in the past day or two, Phil?  Some of your comments =
may be before I did a bunch of work.  Hopefully you have some time to =
look again.  No question marks anymore and they were only temporary =
before I was going to create a help graphic.  Anyway, I think the way =
you did with the one Help at the top is good as long as we document =
clearly, possibly in the first online help screen, that the help will =
change contextually.  Possibly by the menu items you mean the =
menu_group_items or do you mean the main_menu?

  The menus would be javascript.  However, I believe when I did testing =
in several browsers on this site I created www.goldenwitch.com they =
worked on all.  Some people with various browsers could try going to =
that site to see if the drop-down menus work perfectly.  It is minimal =
and very standard javascript.  I agree with avoiding javascript, java =
and any other language as much as possible but you can't make drop-down =
menus unless you have code at the client side.  I think ALL languages =
besides PHP, HTML and CSS should be optional in the config or elsewhere.

  I still have to get up with the cvs thing.  I have it installed but =
haven't tried it out.  When I do something it's all at once so one day =
soon I'll be doing cvs and will send you.

  I saw the user and database in the newest demo.  Something else I =
noticed though was that the Help gave an error.  Can't remember exactly =
where or why right now though.

  Steve

    ----- Original Message -----=20
    From: Daintrees=20
    To: web...@li...=20
    Sent: Sunday, August 01, 2004 4:15 PM
    Subject: Re: [Web-erp-developers] Interface


    I guess this would be java?
    If it could be made to work in all forms of java then it would be a =
useful addition - I have tried to avoid it so far and have no knowlege =
personally. It is nice not to depend on java for anything. I agree it =
would be good.

    I would like to clean the css if you send me the files.=20

    I like the vertical oreintation of the menus - I think it needs some =
spacing between the menu items - they all merge together.
    As previously mentioned I am not so keen on the preponderance of =
question marks. I think this is probably superseeded following our =
discussion on the help.

    I already added the user and database to the titles - in 2.9


    Phil



      ----- Original Message -----=20
      From: skaill=20
      To: web...@li...=20
      Sent: Monday, August 02, 2004 2:35 AM
      Subject: [Web-erp-developers] Interface


      I've been working with the interface quite a bit now.  For those =
who would like to see what I've done go to http://weberp.gocom.ca.  =
Please make many, many comments good or bad.

      While I've been doing this I fixed some incorrect code and cleaned =
it up, especially the css.  There were several places that had commands =
which weren't actually being used and in fact would lead someone to =
think that what they were seeing should be different.  This is typical =
and I'm no exception but I took the time to do some cleanup.  I think it =
is easier to read and understand now.

      Phil, if you like parts of this refined interface or all of it we =
can get it into the base product.  Let me know.

      I'm seriously thinking about adding code that will do drop-down =
menus and allow a user option to specify whether they see the interface =
displayed now or they see drop-down menus.  With the drop-down menus it =
would allow everything to be accessible all the time with little screen =
space taken up.  It also looks pro.  Plus the fast access options become =
basically irrelevant with drop-down menus.

      Steve

Re: [Web-erp-developers] Interface

[skaill <sk...@ro...>]

Have you looked in the past day or two, Phil?  Some of your comments may =
be before I did a bunch of work.  Hopefully you have some time to look =
again.  No question marks anymore and they were only temporary before I =
was going to create a help graphic.  Anyway, I think the way you did =
with the one Help at the top is good as long as we document clearly, =
possibly in the first online help screen, that the help will change =
contextually.  Possibly by the menu items you mean the menu_group_items =
or do you mean the main_menu?

The menus would be javascript.  However, I believe when I did testing in =
several browsers on this site I created www.goldenwitch.com they worked =
on all.  Some people with various browsers could try going to that site =
to see if the drop-down menus work perfectly.  It is minimal and very =
standard javascript.  I agree with avoiding javascript, java and any =
other language as much as possible but you can't make drop-down menus =
unless you have code at the client side.  I think ALL languages besides =
PHP, HTML and CSS should be optional in the config or elsewhere.

I still have to get up with the cvs thing.  I have it installed but =
haven't tried it out.  When I do something it's all at once so one day =
soon I'll be doing cvs and will send you.

I saw the user and database in the newest demo.  Something else I =
noticed though was that the Help gave an error.  Can't remember exactly =
where or why right now though.

Steve

  ----- Original Message -----=20
  From: Daintrees=20
  To: web...@li...=20
  Sent: Sunday, August 01, 2004 4:15 PM
  Subject: Re: [Web-erp-developers] Interface


  I guess this would be java?
  If it could be made to work in all forms of java then it would be a =
useful addition - I have tried to avoid it so far and have no knowlege =
personally. It is nice not to depend on java for anything. I agree it =
would be good.

  I would like to clean the css if you send me the files.=20

  I like the vertical oreintation of the menus - I think it needs some =
spacing between the menu items - they all merge together.
  As previously mentioned I am not so keen on the preponderance of =
question marks. I think this is probably superseeded following our =
discussion on the help.

  I already added the user and database to the titles - in 2.9


  Phil



    ----- Original Message -----=20
    From: skaill=20
    To: web...@li...=20
    Sent: Monday, August 02, 2004 2:35 AM
    Subject: [Web-erp-developers] Interface


    I've been working with the interface quite a bit now.  For those who =
would like to see what I've done go to http://weberp.gocom.ca.  Please =
make many, many comments good or bad.

    While I've been doing this I fixed some incorrect code and cleaned =
it up, especially the css.  There were several places that had commands =
which weren't actually being used and in fact would lead someone to =
think that what they were seeing should be different.  This is typical =
and I'm no exception but I took the time to do some cleanup.  I think it =
is easier to read and understand now.

    Phil, if you like parts of this refined interface or all of it we =
can get it into the base product.  Let me know.

    I'm seriously thinking about adding code that will do drop-down =
menus and allow a user option to specify whether they see the interface =
displayed now or they see drop-down menus.  With the drop-down menus it =
would allow everything to be accessible all the time with little screen =
space taken up.  It also looks pro.  Plus the fast access options become =
basically irrelevant with drop-down menus.

    Steve

Re: [Web-erp-developers] Interface

[Daintrees <p.d...@pa...>]

I guess this would be java?
If it could be made to work in all forms of java then it would be a =
useful addition - I have tried to avoid it so far and have no knowlege =
personally. It is nice not to depend on java for anything. I agree it =
would be good.

I would like to clean the css if you send me the files.=20

I like the vertical oreintation of the menus - I think it needs some =
spacing between the menu items - they all merge together.
As previously mentioned I am not so keen on the preponderance of =
question marks. I think this is probably superseeded following our =
discussion on the help.

I already added the user and database to the titles - in 2.9


Phil



  ----- Original Message -----=20
  From: skaill=20
  To: web...@li...=20
  Sent: Monday, August 02, 2004 2:35 AM
  Subject: [Web-erp-developers] Interface


  I've been working with the interface quite a bit now.  For those who =
would like to see what I've done go to http://weberp.gocom.ca.  Please =
make many, many comments good or bad.

  While I've been doing this I fixed some incorrect code and cleaned it =
up, especially the css.  There were several places that had commands =
which weren't actually being used and in fact would lead someone to =
think that what they were seeing should be different.  This is typical =
and I'm no exception but I took the time to do some cleanup.  I think it =
is easier to read and understand now.

  Phil, if you like parts of this refined interface or all of it we can =
get it into the base product.  Let me know.

  I'm seriously thinking about adding code that will do drop-down menus =
and allow a user option to specify whether they see the interface =
displayed now or they see drop-down menus.  With the drop-down menus it =
would allow everything to be accessible all the time with little screen =
space taken up.  It also looks pro.  Plus the fast access options become =
basically irrelevant with drop-down menus.

  Steve

[Web-erp-developers] Interface

[skaill <sk...@ro...>]

I've been working with the interface quite a bit now.  For those who =
would like to see what I've done go to http://weberp.gocom.ca.  Please =
make many, many comments good or bad.

While I've been doing this I fixed some incorrect code and cleaned it =
up, especially the css.  There were several places that had commands =
which weren't actually being used and in fact would lead someone to =
think that what they were seeing should be different.  This is typical =
and I'm no exception but I took the time to do some cleanup.  I think it =
is easier to read and understand now.

Phil, if you like parts of this refined interface or all of it we can =
get it into the base product.  Let me know.

I'm seriously thinking about adding code that will do drop-down menus =
and allow a user option to specify whether they see the interface =
displayed now or they see drop-down menus.  With the drop-down menus it =
would allow everything to be accessible all the time with little screen =
space taken up.  It also looks pro.  Plus the fast access options become =
basically irrelevant with drop-down menus.
=20
Steve

Fw: [Web-erp-developers] Warehouse Bin Locations

[skaill <sk...@ro...>]

Ok, trying this a third time.  First time it came back saying they don't let
files over 44k through.  Second time it said they block zip files.  So, I
converted it to a text file.  A bit messy but if you bring into a word pro
it should be better.

Steve

----- Original Message ----- 
From: "skaill" <sk...@ro...>
To: <web...@li...>
Sent: Saturday, July 31, 2004 7:41 AM
Subject: Re: [Web-erp-developers] Warehouse Bin Locations


> Hi Danie,
>
> Here is a summary specification that comes from the various documents and
> knowledge I've collected over the years.  It's far from ideal as I just
> created it since I can't give you any proprietary documents I have from
> other companies!
>
> Down the road we will be looking thoroughly into the tax functionality of
> webERP.  If everything in this specification is not covered we will
probably
> be enhancing webERP to cover it.
>
> Keep in mind that as long as the user can manually enter/modify various
> taxes for different jurisdictions on the invoice then at least they can
get
> by even if somewhat painfully.
>
> Feel free to discuss more about tax with me anytime.
>
> Steve
>
> ----- Original Message ----- 
> From: "Danie Brink" <br...@na...>
> To: <web...@li...>
> Sent: Saturday, July 31, 2004 4:48 AM
> Subject: Re: [Web-erp-developers] Warehouse Bin Locations
>
>
> > Quoting skaill <sk...@ro...>:
> >
> > Hi Steve,
> >
> > Please go ahaid and send some specs to me so I can have a look. At the
> very
> > least I want to make it possible to incorporate multiple taxes on an
> Invoice.
> > Well, actualy I still need to do two more screens and convert the Stock
> master
> > table and a couple of others to reference the new structure.
> >
> > Kind Regards.
> > Danie
> >
> > > Hi Danie,
> > >
> > > I may be able to help in some ways with the tax changes.  I spec'd and
> > > rewrote the entire tax functionality for one of the leading world-wide

> > > mid-range erp softwares.  It's one of my specialties ;)
> > >
> > > Steve
> > >
> > > ----- Original Message ----- 
> > > From: "Danie Brink" <br...@na...>
> > > To: <web...@li...>
> > > Sent: Friday, July 30, 2004 3:42 AM
> > > Subject: Re: [Web-erp-developers] Warehouse Bin Locations
> > >
> > >
> > > > Hi Phil
> > > >
> > > > Danie Here,
> > > >
> > > > We have managed to get a small contract for web-erp and we have to
> build
> > > in
> > > > proper manufacturing and job control as well as job costing. We are
> three
> > > > people whom have worked on this type of thing in the past, and we
must
> > > > implement it. What I am realy asking is not to energize yourself to
> fast
> > > we
> > > > have to do this in the next few months, maybe you can once we are
done
> > > have a
> > > > look at it. Also I have to change the Tax system to accomodate the
> client
> > > which
> > > > I will also contribute back. It basicaly involve the seperation of
Tax
> > > > Authority and Tax Types( where Gl Accounts and rates are specified)
> and
> > > then
> > > > the creation of a Stock Tax Category Table which replace the levels
> and
> > > will be
> > > > foreign key linked to Stock master Tax Level ( Replacing Tax Level )
> and
> > > all
> > > > other places Tax Level And Tax Authotity are refferenced. The Tax
> Rates
> > > which
> > > > usualy is an loose assosiation will now be a fixed assosiation
between
> Tax
> > > > authority, Dispatch Tax Auth, Tax Type and Tax Category. This also
> allow
> > > us to
> > > > customize the reports to use the TaxType Report Field for the lookup
> of
> > > the
> > > > actual display name on invoice and also the totaling of different
> taxes of
> > > > items on invoice and display thereof. Also we will be trying to fit
> the
> > > > postgres conversion into the time alotted as well.
> > > >
> > > > Also one we have finished with this client I am trying to put
together
> > > some
> > > > stuff for an exibition booth. I have a Stock Exchange software and
SMS
> > > software
> > > > (windows only, old, but good) which we will be giving away free to
> garner
> > > some
> > > > interest, It will probably be an indisutrial technology exibition.
> > > >
> > > > Kind Regards
> > > > Danie Brink
> > > >
> > > > Quoting Phil Daintree <p.d...@pa...>:
> > > >
> > > > > Nope we don't have warehousing management at all.
> > > > >
> > > > > Really in most situations it is possible to have the same item in
> > > > > several different bins. So a single bin location for each item in
> the
> > > > > stocks master record doesnt really cut it.
> > > > >
> > > > > To do the job properly we are talking about another table for
bins -
> a
> > > > > record for each available bin perhaps that gets updated with the
> > > > > quantity of a part. This then gives us the option to suggest a
> picking
> > > > > run for the dispatch team - but a whole heap more input ....
ideally
> by
> > > > > barcode at the time of picking - scanning serial numbers/batch
> > > > > references as necessary too. This barcode data could then form the
> basis
> > > > > of an automated order confirmation/invoicing run. This would be an
> > > > > interesting project BUT I must now focus on manufacturing once I
get
> > > > > re-energised for another development phase!
> > > > >
> > > > > Phil
> > > > >
> > > > >
> > > > > On Wed, 2004-07-28 at 16:32, Chris Bice wrote:
> > > > > > I know we have a location for inventory but do we have "BIN"
> > > > > > locations.  Like a BIN in the warehouse???  If not, I will plan
on
> > > > > > adding the functionality for that.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Chris
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by BEA Weblogic Workshop
> > > > > FREE Java Enterprise J2EE developer tools!
> > > > > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > > > > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > > > > _______________________________________________
> > > > > Web-erp-developers mailing list
> > > > > Web...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by OSTG. Have you noticed the changes
> on
> > > > Linux.com, ITManagersJournal and NewsForge in the past few weeks?
Now,
> > > > one more big change to announce. We are now OSTG- Open Source
> Technology
> > > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > > _______________________________________________
> > > > Web-erp-developers mailing list
> > > > Web...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by OSTG. Have you noticed the changes
on
> > > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > > one more big change to announce. We are now OSTG- Open Source
Technology
> > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > _______________________________________________
> > > Web-erp-developers mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > one more big change to announce. We are now OSTG- Open Source Technology
> > Group. Come see the changes on the new OSTG site. www.ostg.com
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

[Web-erp-developers] Decimal point and thousands separator

[Daintrees <p.d...@pa...>]

The function

number_format

is used extensively throughout webERP. To have the option of displaying
numbers with different decimal separators and thousands separators then all
that is required is some variables in config.php

$ThousandsSeparator = ",";
$DecimalSeparator = ".";

or in your case:

$ThousandsSeparator = ".";
$DecimalSeparator = ",";

then amending the function calls to number_format to pass these extra
parameters. If you are happy to do a little dirty work editing each script -
from the CVS I am certainly happy to include this Dirk.

The PHP manual extract for number_format follows for your reference...

Phil

string number_format ( float number, int decimals, string dec_point, string
thousands_sep)


number_format() returns a formatted version of number. This function accepts
either one, two or four parameters (not three):

If only one parameter is given, number will be formatted without decimals,
but with a comma (",") between every group of thousands.

If two parameters are given, number will be formatted with decimals decimals
with a dot (".") in front, and a comma (",") between every group of
thousands.

If all four parameters are given, number will be formatted with decimals
decimals, dec_point instead of a dot (".") before the decimals and
thousands_sep instead of a comma (",") between every group of thousands.

Only the first character of thousands_sep is used. For example, if you use
foo as thousands_sep on the number 1000, number_format() will return 1f000.

Re: [Web-erp-developers] Warehouse Bin Locations

[Stins, D. <DR...@Zi...>]

Hoi,

That's right. In The Netherlands (part of Europe), we got VAT (value added
tax) xor insurance tax.

VAT: You only pay for your added value (VAT of your turnover - VAT of
items/services you bought of your suppliers). So you have to pay every month
only VAT for you added value to the taxauthority. When you buy more then you
sell, you get VAT payed by the taxauthority ;)

Insurance tax: you pay tax for all kind of insurances.

There are also several other taxes like for cigarettes, alcoholic drinks,
gasoline, import tax, ...
VAT is the most important to be well implemented.

VAT has several rates (19% luxory goods, 6% food, hairdresser, .. and 0%
export).

With best regards,

Dick Stins


----- Original Message -----
From: "skaill" <sk...@ro...>
To: <web...@li...>
Sent: Saturday, July 31, 2004 1:41 PM
Subject: Re: [Web-erp-developers] Warehouse Bin Locations


> Hi Danie,
>
> Here is a summary specification that comes from the various documents and
> knowledge I've collected over the years.  It's far from ideal as I just
> created it since I can't give you any proprietary documents I have from
> other companies!
>
> Down the road we will be looking thoroughly into the tax functionality of
> webERP.  If everything in this specification is not covered we will
probably
> be enhancing webERP to cover it.
>
> Keep in mind that as long as the user can manually enter/modify various
> taxes for different jurisdictions on the invoice then at least they can
get
> by even if somewhat painfully.
>
> Feel free to discuss more about tax with me anytime.
>
> Steve
>
> ----- Original Message -----
> From: "Danie Brink" <br...@na...>
> To: <web...@li...>
> Sent: Saturday, July 31, 2004 4:48 AM
> Subject: Re: [Web-erp-developers] Warehouse Bin Locations
>
>
> > Quoting skaill <sk...@ro...>:
> >
> > Hi Steve,
> >
> > Please go ahaid and send some specs to me so I can have a look. At the
> very
> > least I want to make it possible to incorporate multiple taxes on an
> Invoice.
> > Well, actualy I still need to do two more screens and convert the Stock
> master
> > table and a couple of others to reference the new structure.
> >
> > Kind Regards.
> > Danie
> >
> > > Hi Danie,
> > >
> > > I may be able to help in some ways with the tax changes.  I spec'd and
> > > rewrote the entire tax functionality for one of the leading world-wide
> > > mid-range erp softwares.  It's one of my specialties ;)
> > >
> > > Steve
> > >
> > > ----- Original Message -----
> > > From: "Danie Brink" <br...@na...>
> > > To: <web...@li...>
> > > Sent: Friday, July 30, 2004 3:42 AM
> > > Subject: Re: [Web-erp-developers] Warehouse Bin Locations
> > >
> > >
> > > > Hi Phil
> > > >
> > > > Danie Here,
> > > >
> > > > We have managed to get a small contract for web-erp and we have to
> build
> > > in
> > > > proper manufacturing and job control as well as job costing. We are
> three
> > > > people whom have worked on this type of thing in the past, and we
must
> > > > implement it. What I am realy asking is not to energize yourself to
> fast
> > > we
> > > > have to do this in the next few months, maybe you can once we are
done
> > > have a
> > > > look at it. Also I have to change the Tax system to accomodate the
> client
> > > which
> > > > I will also contribute back. It basicaly involve the seperation of
Tax
> > > > Authority and Tax Types( where Gl Accounts and rates are specified)
> and
> > > then
> > > > the creation of a Stock Tax Category Table which replace the levels
> and
> > > will be
> > > > foreign key linked to Stock master Tax Level ( Replacing Tax Level )
> and
> > > all
> > > > other places Tax Level And Tax Authotity are refferenced. The Tax
> Rates
> > > which
> > > > usualy is an loose assosiation will now be a fixed assosiation
between
> Tax
> > > > authority, Dispatch Tax Auth, Tax Type and Tax Category. This also
> allow
> > > us to
> > > > customize the reports to use the TaxType Report Field for the lookup
> of
> > > the
> > > > actual display name on invoice and also the totaling of different
> taxes of
> > > > items on invoice and display thereof. Also we will be trying to fit
> the
> > > > postgres conversion into the time alotted as well.
> > > >
> > > > Also one we have finished with this client I am trying to put
together
> > > some
> > > > stuff for an exibition booth. I have a Stock Exchange software and
SMS
> > > software
> > > > (windows only, old, but good) which we will be giving away free to
> garner
> > > some
> > > > interest, It will probably be an indisutrial technology exibition.
> > > >
> > > > Kind Regards
> > > > Danie Brink
> > > >
> > > > Quoting Phil Daintree <p.d...@pa...>:
> > > >
> > > > > Nope we don't have warehousing management at all.
> > > > >
> > > > > Really in most situations it is possible to have the same item in
> > > > > several different bins. So a single bin location for each item in
> the
> > > > > stocks master record doesnt really cut it.
> > > > >
> > > > > To do the job properly we are talking about another table for
bins -
> a
> > > > > record for each available bin perhaps that gets updated with the
> > > > > quantity of a part. This then gives us the option to suggest a
> picking
> > > > > run for the dispatch team - but a whole heap more input ....
ideally
> by
> > > > > barcode at the time of picking - scanning serial numbers/batch
> > > > > references as necessary too. This barcode data could then form the
> basis
> > > > > of an automated order confirmation/invoicing run. This would be an
> > > > > interesting project BUT I must now focus on manufacturing once I
get
> > > > > re-energised for another development phase!
> > > > >
> > > > > Phil
> > > > >
> > > > >
> > > > > On Wed, 2004-07-28 at 16:32, Chris Bice wrote:
> > > > > > I know we have a location for inventory but do we have "BIN"
> > > > > > locations.  Like a BIN in the warehouse???  If not, I will plan
on
> > > > > > adding the functionality for that.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Chris
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by BEA Weblogic Workshop
> > > > > FREE Java Enterprise J2EE developer tools!
> > > > > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > > > > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > > > > _______________________________________________
> > > > > Web-erp-developers mailing list
> > > > > Web...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by OSTG. Have you noticed the changes
> on
> > > > Linux.com, ITManagersJournal and NewsForge in the past few weeks?
Now,
> > > > one more big change to announce. We are now OSTG- Open Source
> Technology
> > > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > > _______________________________________________
> > > > Web-erp-developers mailing list
> > > > Web...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by OSTG. Have you noticed the changes
on
> > > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > > one more big change to announce. We are now OSTG- Open Source
Technology
> > > Group. Come see the changes on the new OSTG site. www.ostg.com
> > > _______________________________________________
> > > Web-erp-developers mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > one more big change to announce. We are now OSTG- Open Source Technology
> > Group. Come see the changes on the new OSTG site. www.ostg.com
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [Web-erp-developers] How Does Open Source Dovetail with the Commercial World

[skaill <sk...@ro...>]

It's awesome that you have created webERP, Phil.  Even more awesome that you
have made it available for others and for free.

Regardless of who creates what and for how much, in general and when doing
consulting work for a company (customer) it is important not to reinvent the
wheel.  If we go crazy working on a product for months and charge a customer
thousands when someone is selling what would have done the customer for $400
or it is Open Source then we aren't going to look too good in the long run.
At the same time there has to be enough work and profit to make it worth
doing for a customer in the case of the product not making us a profit by
selling it.  This is the challenge but I believe there are advantages as
well as disadvantages and there are ways to make it work for all.

People decide what software to use in the same way they vote for a
president/prime minister.  If it looks good and says the right things then
it must be good.  Unfortunate, but reality.  To get more people to consider
a good product then it kind of means that the fluff becomes necessary.
Sometimes fluff isn't just fluff as it would first seem as well.  For
example research over the years shows that filling more than about half of a
screen leads to slower interfacing.  1 in 20 Caucasian males are color
blind.

Steve

----- Original Message ----- 
From: "Daintrees" <p.d...@pa...>
To: <web...@li...>
Sent: Friday, July 30, 2004 7:34 PM
Subject: [Web-erp-developers] How Does Open Source Dovetail with the
Commercial World


> >
> > By the way, we may have our first webERP customer.  We'll know within a
> few
> > weeks.  It's being readied to show them.  We'll be doing some industry
> > specific modifications for their industry in order to impress them ;)
> >
> Brilliant! Good luck with this.
>
> Thanks for the background Steve .... maybe I take this stuff too lightly
> since it is a hobby for me - I don't need to make money from this - of
> course it would be nice but I do get pleasure from talking to you folks
and
> the developing of the project. My wife thinks I'm stupid giving it away!
> Probably am, but I take NO joy in marketing I am a product person/engineer
> at heart - accountant by trade..... definitely NOT a marketeer. As you
point
> out commercial software is about marketing and first impressions. I'm not
so
> interested in this as you know and my actions in releasing web-erp as open
> source does have the potential to make life difficult for commercial
> accounting software businesses. I'm not a deliberate spoiler. Its just
that
> I spent a long time making something I am proud of (ego must be the
driver)
> and think it is useful. I would much rather it be used than rot on my hard
> drive as just one massive waste of time.
>
> Open Source does seem like a spanner in the works of commercial software
> activity and probably tends to devalue the skills of professional
> programmers like yourself. For this I am sorry. However, I don't object to
> others making money off my efforts with a bit of marketing on their part -
I
> just think I deserve a right of refusal to include any improvements into
it.
>
>
> Phil
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] little wishlist

[skaill <sk...@ro...>]

I would suggest in the config that there is a variable that would be the
thousands separator and another variable for the decimal separator.  I
believe in Europe, $1,000.98 is 1.000,98$.  Possibly the dollar sign doesn't
go there but I think I've seem that way.

Possibly Dirk could look at the spec I sent to see if it would cover most or
all of what is needed.

Steve

----- Original Message ----- 
From: "Danie Brink" <br...@na...>
To: <web...@li...>
Sent: Saturday, July 31, 2004 4:44 AM
Subject: Re: [Web-erp-developers] little wishlist


> Hi Dirk
>
> Danie Here
>
> Could you send me a more thorough description as I am in the process of
> customizing the Taxes to work more modular so I might as well look at your
> requirement and try to incorporate it.
>
>
> Kind Regards
> Danie Brink
>
> Quoting Dirk Eversmann <dir...@gr...>:
>
> > Dear Developers,
> >
> > unfortunately I am not verry good developing this great program much
> > further (lack of knowledge in PHP).
> > So I will post my oppinion to your latest discussions:
> >
> > I would be happy about a more modular structure. I think, some users
could
> > add eg. different languages. What about templets? I am not sure, if it
is
> > still popular to splitt php-code and html? If someone tells me what to
do,
> > I would be glad to spend some time doing the 'dirty work'.
> >
> > Still my biggest problem with webERP: The Tax-thing. The german needs to
> > splitt sales and costs to different GL-accounts -depending on tax-rate
and
> > situation- as well as to different tax GL-accounts. To make this more
clear:
> > The rates are: 0%, 7% and 16%
> > The situations are: Purchasing and selling in Germany (0%, 7% and 16%),
in
> > European Union to private (0%, 7% and 16%), in EU to business (0%),
world
> > (0%).
> > Having different sales accounts (according to tax-level) also makes some
> > sence: One can easily check, if everything is ok: running total
GLsales16%
> > = 100 > running total GLtax16%=16
> > I have to report (and pay :-( ) my VAT every month and by now, I correct
> > the GL-bookings by hand....
> >
> > Just a tiny wish: comma and decimal point is used here just the other
way
> > around. Would be greate, one could change this in the config.php
> >
> > Have a nice day, Dirk
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > one more big change to announce. We are now OSTG- Open Source Technology
> > Group. Come see the changes on the new OSTG site. www.ostg.com
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers