web-erp-developers — Discussion on development of webERP

Re: [Web-erp-developers] Re: [Web-erp-users] Managing Modifications

[Sherif O. <sh...@ky...>]

Hi Phil,

Hani is handling the PDF issue, I don't really know the details of why it's
not working , I should have tested it sooner - totally my fault! I was just
using it as an example of what can go wrong once all the developers on a
project are not aware of what the others are working on.

There are two solutions now, either :
    *  To find another (also open-source, compact) class like R&OS that has
proper localization support (I should add - you can't even display the EURO
symbol without major headache). We will then handle porting to the new
library.
    * Fix R&OS and add localization support to it.

As I said, Hani is handling this issue and he will weigh in on this in a few
days - I should ask though that no more porting to R&OS be done until we all
further discuss where we are going with this.

regards
Sherif

----- Original Message ----- 
From: "Phil Daintree" <ph...@du...>
To: <web...@li...>
Sent: Thursday, August 28, 2003 4:04 AM
Subject: [Web-erp-developers] Re: [Web-erp-users] Managing Modifications


> Hi Sherif,
>
> Thats a shame about R&OS localisation support, since you hadn't come back
on
> that I assumed - wrongly - there was no problem.
>
> Trying to look at the positives, the performance of this class and the
> portability that it provides in terms of one less piece of server software
> reliance is a great plus for the system and the absence of the onerous
> lisencing is I suspect another serious plus for a lot of potential users.
> Whilst it will make the localisation project more interesting it adds good
> value to the english version. On their behalf at least, thanks for
> suggesting it!
>
> Although I have not looked into it, the code is of course available here
too
> I am not sure what sort of localisation support we need - could we add it
to
> the R & OS code?
>
> Whilst localisation would be great, as you know I do have some
reservations
> about the complexity it would add. Maybe it is best to accept that WEB-ERP
> will not be and cannot be all things to all people.
>
> Phil
>
> > A good example of a problem that can arise from incomplete coordination
is
> > that one of the PDF libraries being used (ROS) has no localization
support
> > whatsoever.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [Web-erp-developers] Re: [Web-erp-users] Managing Modifications

[Sherif O. <sh...@ky...>]

Hi Phil,

I agree fully that a list will not be suitable in all cases, that is why it
will be a user option. I just did the basic thing for now and for sure there
are many improvements to be done before it is fully working. For example :

* If the count of items is greater than a certain number, it will switch
automatically to the search facility (and vice versa).
* For stock items, have 2 lists, 1 for categories, 1 for stock items of the
selected category.
* Have buttons/links that limit what is displayed in a list. "A-H", "I-R",
"S-Z" will display only the items that start in that range.

cheers !
Sherif

----- Original Message ----- 
From: "Phil Daintree" <ph...@du...>
To: "Web ERP Developers" <Web...@li...>
Sent: Thursday, August 28, 2003 3:47 AM
Subject: [Web-erp-developers] Re: [Web-erp-users] Managing Modifications


> Sherif,
>
> Just a point on the list box for stock or customers.
>
> To populate these list boxes in a live environment we are looking at
> possibly thousands of customers and thousands of parts. The recent
> implementation I did was around 2,000 customers I think.
>
> The worry I have is that I am not sure that a dial up user would be so
keen
> to wait for all the data required for the select box to come down the
wire.
> A user would need to be able to turn this off if she was working remotely
> today where normally she works in the office. Would the user think to turn
> it off - may just get frustrated with the wait and the perceived poorness
of
> the system they've been given.
>
> It was my view that the search facility with a limit on the number of
> records returned I feel meets the aim of minimising the bandwidth better.
>
> Any comments from anyone else appreciated.
>
> Phil
>
> ----- Original Message -----
> From: "Sherif Omar" <sh...@ky...>
> To: <web...@li...>
> Sent: Wednesday, August 27, 2003 6:24 PM
> Subject: [Web-erp-users] Managing Modifications
>
>
> > Hi Phil/Everybody,
> >
> > It seems that there are more and more people who will be contributing to
> the
> > development of web-erp, and I think we need to work out a more
structured
> > approach to managing the source, to avoid :
> >
> > * Different people doing the same thing in different ways.
> > * Somebody doing something that conflicts with existing work or work in
> > progress.
> >
> > Maybe we should have a noticeboard of what work is required, who is
> working
> > on what, etc. For example, we are currently working on :
> >
> > 1 - modifying all the scripts to be localizable.
> >
> > 2 - adding UI functions for repeated operations (eg.
bankAccountsList(...)
> > displays a list of bank accounts, locationsList(...) displays a list of
> > inventory locations).
> >
> > 3 - an option to make supplier,customer and stock item selection use a
> list
> > instead of a search facility. This will be a user-level option.
> >
> > A good example of a problem that can arise from incomplete coordination
is
> > that one of the PDF libraries being used (ROS) has no localization
support
> > whatsoever.
> >
> > regards
> > Sherif
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Web-erp-users mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-users
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

[Web-erp-developers] Re: [Web-erp-users] Managing Modifications

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

Hi Sherif,

Thats a shame about R&OS localisation support, since you hadn't come back on
that I assumed - wrongly - there was no problem.

Trying to look at the positives, the performance of this class and the
portability that it provides in terms of one less piece of server software
reliance is a great plus for the system and the absence of the onerous
lisencing is I suspect another serious plus for a lot of potential users.
Whilst it will make the localisation project more interesting it adds good
value to the english version. On their behalf at least, thanks for
suggesting it!

Although I have not looked into it, the code is of course available here too
I am not sure what sort of localisation support we need - could we add it to
the R & OS code?

Whilst localisation would be great, as you know I do have some reservations
about the complexity it would add. Maybe it is best to accept that WEB-ERP
will not be and cannot be all things to all people.

Phil

> A good example of a problem that can arise from incomplete coordination is
> that one of the PDF libraries being used (ROS) has no localization support
> whatsoever.

[Web-erp-developers] Re: [Web-erp-users] Managing Modifications

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

Sherif,

Just a point on the list box for stock or customers.

To populate these list boxes in a live environment we are looking at
possibly thousands of customers and thousands of parts. The recent
implementation I did was around 2,000 customers I think.

The worry I have is that I am not sure that a dial up user would be so keen
to wait for all the data required for the select box to come down the wire.
A user would need to be able to turn this off if she was working remotely
today where normally she works in the office. Would the user think to turn
it off - may just get frustrated with the wait and the perceived poorness of
the system they've been given.

It was my view that the search facility with a limit on the number of
records returned I feel meets the aim of minimising the bandwidth better.

Any comments from anyone else appreciated.

Phil

----- Original Message -----
From: "Sherif Omar" <sh...@ky...>
To: <web...@li...>
Sent: Wednesday, August 27, 2003 6:24 PM
Subject: [Web-erp-users] Managing Modifications


> Hi Phil/Everybody,
>
> It seems that there are more and more people who will be contributing to
the
> development of web-erp, and I think we need to work out a more structured
> approach to managing the source, to avoid :
>
> * Different people doing the same thing in different ways.
> * Somebody doing something that conflicts with existing work or work in
> progress.
>
> Maybe we should have a noticeboard of what work is required, who is
working
> on what, etc. For example, we are currently working on :
>
> 1 - modifying all the scripts to be localizable.
>
> 2 - adding UI functions for repeated operations (eg. bankAccountsList(...)
> displays a list of bank accounts, locationsList(...) displays a list of
> inventory locations).
>
> 3 - an option to make supplier,customer and stock item selection use a
list
> instead of a search facility. This will be a user-level option.
>
> A good example of a problem that can arise from incomplete coordination is
> that one of the PDF libraries being used (ROS) has no localization support
> whatsoever.
>
> regards
> Sherif
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Web-erp-users mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-users
>

[Web-erp-developers] Re: Web-ERP participation

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

MessageHi Shane/Paul,

Wow ... your cosmetic makeover is stunning!

I guess you can tell my background is accounting and not graphic design. The
workman like interface is probably a black mark against the system by some
potential users.

It would be great to be able to include your contributions into the system.
Also, it would ultimately be great NOT to have the system dependent on me
and you gentlemen certainly seem extremely capable. Thanks for applying your
heads to improving WEB-ERP.

If you've been following the discussion in the developers list, then you
will probably have been exposed to some of my excentricities - I'm English
and not a programmer although have certainly tried to read widely on the
subject. I have no knowledge of XHTML/XML/XSL/Javascript. Although I would
like to extend my knowledge with the first 3.

You will note from the web site the aims with this application is:

1. To be "low footprint" efficient and fast, with absolutely minimal network
traffic to enable dial up low bandwidth connections to have a reasonable
response. This will require some compromises with graphics I fear, but still
plenty of opportunities with judicious use of css.

2. Runnable in any browser - with no dependence on proprietory software. I
have steered deliberately away from Java due to the inconsistencies I have
seen in the interpreters and ultimately making the system depend on a given
implementation. This may be an over-reaction. See NOLA and derivatives for
the problems that resulted. Java also increases the bandwidth requirements
with downloading the software - although I recognise there can also be a
saving in "round trips" to the server. Java is not available on some PDA
browsers and it takes memory and processing power at the client. Very keen
to keep the software requirements at the browser end as minimal as
possible - just a pdf reader (a little worried about the size of Acrobat
6.0!!) and a browser.

3. Scripts readable and modifiable by folks without computer science
degrees.  You will notice extensive use of plain english throughout - not
especially helpful to non-english speakers. I also have some problems with
what I consider too many levels of abstraction which whilst beautiful from a
programmers re-use perspective I think detracts from ease of understanding
the script. Flying in the face of traditional accepted programming practice,
I feel there are real advantages to mixing up the display - or at least the
text of what is displayed with the logic - I rekon the output adds context
to the logic. I know I have looked at some 3rd party scripts that are
probably beautifully written from the programming perspective but just too
hard for a simple layman to get his few cells around. This puts the mokkers
on using templates and other programming niceties!

To that end also, the use of technologies beyond the simple core PHP/HTML is
probably to be avoided unless there is no other way to acheive the end
result ie technology for technology's sake is to be avoided. I am aware that
XML/SOAP EDI would be a wonderful extension to the system and that HTML/PHP
on their own may not be able to cut the mustard - unless someone has done a
PEAR module on it?

I do fervently hope these foibles are not too much of a detraction from your
wishing to contibute. I hope I am open to logical argument about the wisdom
of changing these views. I would hate for my lack of ability to be holding
back the system - but the appeal to non-programmers is also important.
I am excited about the possibilities and new appeal the face lift should
give the system and am keen to learn from your knowledge.

There are a growing number of interested parties:

Sherif Omar and Hani from Kylitech in Cairo are working on localis(z)ation.
Chris Bice is helping with the mailing list and also conversion to R & OS
pdf-php class from pdflib

These gentlemen are busy chaps with businesses to run so most of the
development has been mine to date.

How we administer the development and divide the effort was a topic Sherif
raised yesterday. It would certainly be good for each of us to post on this
list the areas that we wish to apply our focus to, so that we don't get into
a position where several of us are working on the same thing. I did try to
co-ordinate the effort with the conversion to R & OS pdf-php class but I
think we would all agree it wasn't that successful.

My view - post the R & OS pdf-php class mods - is if you have something to
contribute, then great and thanks very much. If I understand it and it tests
out ok for me I will include it and commit it to CVS. If you do regular
updates from the CVS the modified scripts are then available immediately - I
will commit changes as I receive them (after testing) some diligence in the
entries into the change log would also be good! The update from CVS will
show you those scripts that changed since your last update and the change
log should spell out why.

I personally would prefer little and often updates to be submitted, rather
than biggies occassionaly. Biggies are a little daunting and take a bit of
time to digest.


Phil
  ----- Original Message -----
  From: Shane Barnaby
  To: 'ph...@du...'
  Sent: Thursday, August 28, 2003 5:11 AM
  Subject: Web-ERP participation


  Dear Phil Daintree,

  My name is Shane Barnaby and I am writing to see you would like some
assistance on the Web-ERP project. I am the Web Administrator for a small
manufacturing company in Vancouver BC, Canada. Myself and the System
Administrator, Paul Clark, stumbled across Web-ERP on the Sourceforge
website a few weeks ago. We have been reviewing the code base and have
concluded that Web-ERP is a good fit for our company.

  Both Paul and myself would like to congratulate you on your work. Web-ERP
has many features and the MySQL database is well laid out. You have created
a great foundation to grow.

  I have made some minor changes already, such as, reorganized the file
structure and updated the interface. These changes were made simply to
present Web-ERP in its best light to our colleagues. However, there is much
I feel can be contributed from our involvement. Specifically, I have
experience with XML, XSL and related technologies. I also have practical
experience with XHTML, CSS, PHP, JavaScript, ASP, VBScript and graphic
design. Paul is a database guru.

  I have already added the support for "Themes" by moving styles to CSS and
reorganizing directory structure. I also separated out headers and footers
and begun converting HTML to transitional XHTML.  Attached you will find
example screen shots to give you an idea of what we have been up to. I would
also like to send you the code we have been working if interested.

  Ultimately, both Paul and myself would like contribute to the project and
coordinate efforts. Please let me know if you feel our involvement will be
of benefit to the project.

  Shane Barnaby
  Web Administrator
  Alco Ventures Inc.
  sba...@al...
  www.alcoventures.com
  tell: 604.513.2527
  fax: 604.513.2528

[Web-erp-developers] Re: [Web-erp-users] Source Code Control

[Daintree F. <p.d...@xt...>]

Hi Richard,

In an acronym - CVS - Concurrent Version Control.

I commit any changes I make almost daily to the CVS on sourceforge, you can
get the very latest scripts from cvs and submit them back to me for review
and committing back to the CVS. All you need to do is get the latest scripts
before you start work - then send me the completed scripts when your done. I
can use diff to see the changes you have made and will commit them to the
cvs. There is an excellent primer on sourceforge for getting started with
it.

Whilst it is a bit of extra work for me, I am very appreciative of the input
and like to know whats gone in to the system in any case. I set the cvs up
at the request of some eygptian chaps who were doing work on language
conversion I have been diligently committing my changes to the cvs each
night.

I am not sure if you work on windows or other OS. A zip or gz or bz2 file
all work for me of the scripts you change. I tend to work on the system
between LA time 1:00am and 4am - so unlikely we'll be working on the same
scripts at the same time!

It's great to have plenty of comments and if you could add commentary on
your changes to the change.log that would be great too.

There's a list for developers - who I have copied in. Sherif has submitted
quite a few improvements and his offsider Hani has stated an intention to
get into it. Also Chris Bice whose interest I believe was in conversion to R
& OS pdf-php class ie getting away from pdflib and the expensive liscencing.

All input is very gratefully received.

Phil


----- Original Message -----
From: "Richard Story PBPC" <rs...@pb...>
To: <web...@li...>
Sent: Tuesday, August 26, 2003 5:20 PM
Subject: [Web-erp-users] Source Code Control


> How do we control the source code.  I need to make changes
> at the same time you do.  We are bound to work on the same
> piece of code at some stage.
>
> How do I submit a piece of code/an amended program?
>
> Suggestions
> -----------
> 1. I can clearly comment my changes and leave it to you to insert.
>    But that would seem to add significantly to your effort.
> 2. I can get everything ready on version X, and then get version X+1
>    (while you make no changes), insert my changes and then ship the
>    code back as fast as possible.  But what if you need to make
>    changes in the interim?
>
> How do other (and sometimes bigger more complex) OS projects handle this?
> How do I know for sure that I have the very latest version?
>
>
>
> Regards
> Richard
> rs...@ia...
> (27) 83 407 3931

[Web-erp-developers] CVS

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

Gentlemen,

The system is available now off the sourceforge CVS server under the module
name 0.2.0
I had uploaded it to CVS when I had enough files together six months or so
ago. I uploaded it to web-erp module at that time. I didn't know how to
remove that whole module and start afresh so I made up this new module
0.2.0. So in short don't use the web-erp module use the 0.2.0 module
instead.

I have been using it happily for 10 days or so and all appears to be working
well.

I also set up Hani as a developer with commit access to the CVS.

There appears to have been a flurry of activity with people trying the
system and the stats are currently showing 93% although I think there are
some issues there on the Sourceforge site. However, it is very encouraging.

Phil

[Web-erp-developers] CVS

[Daintree F. <p.d...@xt...>]

I uploaded the latest into sourceforge cvs and it is now available.
It would be good to use some rigour with the change log also. Perhaps a date
field also for change line would be good?

Phil

Re: [Web-erp-developers] Language

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

Hani,

OK I think I understand the reasons for _set now.
I made my point about the use of _ (I don't like it) but hey ... you guys
are doing the development here and if you are happy I am too!

The conversion to R & OS php.pdf class is taking a little longer than I
anticipated. If Chris has any scripts to include or you and Sherif have done
any work on this then the language conversion should take place after these
new report scripts are committed. A user reported a problem under windows
with the invoice PrintCustTrans.php script. I know you chaps work in
windows - does it work ok for you?

I am hoping if the cvs server is up later I will get the latest into CVS
tonight - currently the CVS contains a very only version. I have a regular
trickle of slightly modified scripts coming through still from the
implementation just completed.

Phil


----- Original Message -----
From: "Hani Naguib" <ha...@na...>
To: <web...@li...>
Sent: Monday, August 04, 2003 11:42 AM
Subject: Re: [Web-erp-developers] Language


> Hi Phil, with regards to the _set function. It is not actually
> equivalent to =
>
> Within the strings inside _("") variables such as ${name} are only
> place holders, and not variables. note the {}. Php is not going to
> replace ${name} with the value of a variable $name. Uhmmm, I dont
> think my explanation is very clear! What _set actually does is store
> the value in a hashtable so that the gettext functions can get to them
> when it needs them.
>
> So we do need a function call, the actual name of the function _set is
> up to us.
>
> With regards to the _() I actually have got used to it. I tried
> changing it to gettext() but I found it cluttered the code.
>
> Me and Sherif reckon it will take us around 2 weeks to get all the
> pages updated. We have another collegue who will be actually creating
> a translation file for Arabic and testing the system to make sure
> we dont break it :)
>
> I think once we have done that (and tested it with arabic, ironed out
> the process etc) we can make the translation file for people to
> translate into other languages.
>
>
> With regards to localization there are few other areas which needs
> to be taken into consideration.
>
> 1- Page orientation: the 'dir' field in the <html> tag, seems to handle
> that well and I dont think we will have any problems.
> 2- Localised images: Because images can have text in them, it is
> consivable that we will need separate images for a given 'logical'
> image. I dont think that will be a problem. Instead of <DEFANGED_IMG
> src="/images/logo.jpg".... we could have something like <DEFANGED_IMG
src=res
> ("/images/logo.jpg").... The res() function will look for the image
> initially in the locale specific location if it cannot find it, it can
> revert to the default location.
> 3- Date/Time formats: I am not sure how to handle it, but should not
> be too much of a problem.
>
> Any other issues?
>
>

Re: [Web-erp-developers] Language

[Hani N. <ha...@na...>]

Hi Phil, with regards to the _set function. It is not actually 
equivalent to =

Within the strings inside _("") variables such as ${name} are only
place holders, and not variables. note the {}. Php is not going to
replace ${name} with the value of a variable $name. Uhmmm, I dont 
think my explanation is very clear! What _set actually does is store
the value in a hashtable so that the gettext functions can get to them
when it needs them.

So we do need a function call, the actual name of the function _set is
up to us.

With regards to the _() I actually have got used to it. I tried 
changing it to gettext() but I found it cluttered the code.

Me and Sherif reckon it will take us around 2 weeks to get all the 
pages updated. We have another collegue who will be actually creating
a translation file for Arabic and testing the system to make sure 
we dont break it :)

I think once we have done that (and tested it with arabic, ironed out
the process etc) we can make the translation file for people to 
translate into other languages.


With regards to localization there are few other areas which needs
to be taken into consideration.

1- Page orientation: the 'dir' field in the <html> tag, seems to handle
that well and I dont think we will have any problems.
2- Localised images: Because images can have text in them, it is 
consivable that we will need separate images for a given 'logical' 
image. I dont think that will be a problem. Instead of <img 
src="/images/logo.jpg".... we could have something like <img src=res
("/images/logo.jpg").... The res() function will look for the image
initially in the locale specific location if it cannot find it, it can
revert to the default location.
3- Date/Time formats: I am not sure how to handle it, but should not
be too much of a problem.

Any other issues?


> Hi Hani,
> 
> This looks great - a super solution that retains all the 
readability -
> clever stuff :-)
> 
> The only points I would make are:
> 
> 1. I don't understand what the _set() function does if it is just 
assigning
> one vble to another - what's wrong with = which is understood in 
every
> language ?
> 2. I think use of the _ is dodgy since it implies PHP system 
variables _POST
> _SESSION _SERVER _GET _HTTP_VARS and it doesn't help with 
understanding the
> logic.
> 
> But relaxed if you think it is good.
> 
> I am grateful/relieved that we will not trash the meaning of the 
scripts
> with multi-language functionality.
> Thanks very much for your input. I certainly don't want to put you 
chaps off
> with my silly ways!
> 
> Phil
> 
> 
> 
> ----- Original Message -----
> From: "Hani Naguib" <ha...@na...>
> To: <Web...@li...>
> Sent: Sunday, August 03, 2003 10:36 PM
> Subject: Re: [Web-erp-developers] Language
> 
> 
> > I apologise if some of you get this message twice. This is because 
the
> > original one had large attachments that seems to have maxed the 
mailing
> > list capacity.
> >
> > Original email:
> > --------------
> >
> > Hi Phil,
> >
> > The function name was actually something I added so it is 
completely
> > up to us, I actually choose that because I thought you would 
probably
> > like something that stays out of the way :) The default function 
name
> > is gettext.
> >
> > I have attached a copy of the a file I changed together with the
> > original file.
> > (Note: Currently the page has to include ("lang/lang.php"), once I
> > am certain about all this that can be moved into header.inc.
> >
> > I also attached an image of the editor I use to enter the strings.
> >
> > Let me know what you think.
> >
> > Hani
> 
> > --
> >
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites 
including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-
url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 
> 

-- 

Re: [Web-erp-developers] Language

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

Hi Hani,

This looks great - a super solution that retains all the readability -
clever stuff :-)

The only points I would make are:

1. I don't understand what the _set() function does if it is just assigning
one vble to another - what's wrong with = which is understood in every
language ?
2. I think use of the _ is dodgy since it implies PHP system variables _POST
_SESSION _SERVER _GET _HTTP_VARS and it doesn't help with understanding the
logic.

But relaxed if you think it is good.

I am grateful/relieved that we will not trash the meaning of the scripts
with multi-language functionality.
Thanks very much for your input. I certainly don't want to put you chaps off
with my silly ways!

Phil



----- Original Message -----
From: "Hani Naguib" <ha...@na...>
To: <Web...@li...>
Sent: Sunday, August 03, 2003 10:36 PM
Subject: Re: [Web-erp-developers] Language


> I apologise if some of you get this message twice. This is because the
> original one had large attachments that seems to have maxed the mailing
> list capacity.
>
> Original email:
> --------------
>
> Hi Phil,
>
> The function name was actually something I added so it is completely
> up to us, I actually choose that because I thought you would probably
> like something that stays out of the way :) The default function name
> is gettext.
>
> I have attached a copy of the a file I changed together with the
> original file.
> (Note: Currently the page has to include ("lang/lang.php"), once I
> am certain about all this that can be moved into header.inc.
>
> I also attached an image of the editor I use to enter the strings.
>
> Let me know what you think.
>
> Hani

> --
>
>

Re: [Web-erp-developers] Language

[Hani N. <ha...@na...>]

I apologise if some of you get this message twice. This is because the
original one had large attachments that seems to have maxed the mailing
list capacity.

Original email:
--------------

Hi Phil,

The function name was actually something I added so it is completely
up to us, I actually choose that because I thought you would probably
like something that stays out of the way :) The default function name
is gettext.

I have attached a copy of the a file I changed together with the
original file. 
(Note: Currently the page has to include ("lang/lang.php"), once I 
am certain about all this that can be moved into header.inc.

I also attached an image of the editor I use to enter the strings.

Let me know what you think.

Hani



> That looks like a great solution albeit a function named _ doesn't 
give much
> away maybe
> 
> echo language("login");
> 
> I set up CVS back when I first started the project and never used it 
since
> there was only me back then. I have to get the Sourceforge team to 
delete
> this old stuff first before I can import the fresh stuff. Sorry to 
hold up
> the works.
> 
> Phil
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites 
including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-
url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 
> 

-- 

[Web-erp-developers] Language

[Daintree F. <p.d...@xt...>]

That looks like a great solution albeit a function named _ doesn't give much
away maybe

echo language("login");

I set up CVS back when I first started the project and never used it since
there was only me back then. I have to get the Sourceforge team to delete
this old stuff first before I can import the fresh stuff. Sorry to hold up
the works.

Phil

Re: [Web-erp-developers] Language

[Hani N. <ha...@na...>]

How about this then:

Instead of:
    echo "Login";
Turned into
    echo _("Login");

This way your pages still have the English text (the default) 
but the function will return the proper version if another language
has been selected. This is how gettext works, but I dont think we
should use gettext since most ISPs dont support it. Although we might
want to use its file format, since there are may tools such as editors
that help creating a new language version.

With regards to the two versions, I will also try to keep them insync.

Hani

> Hani,
> 
> Readability is fundamental and critical to me because:
> 
> 1. I would like it to be accessible to as many people as possible.
> 2. I would like it to be easy for developers to make mods to suit any 
given
> business requirement.
> 
> In my opinion - and I realise this is contrary to accepted programming
> principles - the text of what is output adds context to the logic - to
> seperate the two runs counter to the aim of improving the ease of
> understanding of the script.
> 
> Obviously making the system multi language dramatically increases its 
appeal
> to a larger audience - thus satisfying 1 above but I feel that 2 will
> suffer.
> 
> I am thinking that at least in the short term a seperate offshoot for 
the
> multi-language version might be appropriate until I am convinced we 
will not
> be compromising the system with respect to 2.
> 
> I will upload the current state of the system to the CVS and yes you 
will
> need to set up an account.with sourceforge and let me know you 
username so I
> can add you to the developers with permissions to upload to CVS.
> 
> I will maintain and apply improvements to the logic/functionality in 
the CVS
> multi-language version to the english version and vice-versa. It may 
become
> impossible for me to keep up with this in the longer term but lets 
see how
> we go.
> 
> Phil
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-
url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 
> 

-- 

Re: [Web-erp-developers] Language

[Hani N. <ha...@na...>]

How about this then:

Instead of:
    echo "Login";
Turned into
    echo _("Login");

This way your pages still have the English text (the default) 
but the function will return the proper version if another language
has been selected. This is how gettext works, but I dont think we
should use gettext since most ISPs dont support it. Although we might
want to use its file format, since there are may tools such as editors
that help creating a new language version.

With regards to the two versions, I will also try to keep them insync.

Hani

> Hani,
> 
> Readability is fundamental and critical to me because:
> 
> 1. I would like it to be accessible to as many people as possible.
> 2. I would like it to be easy for developers to make mods to suit any 
given
> business requirement.
> 
> In my opinion - and I realise this is contrary to accepted programming
> principles - the text of what is output adds context to the logic - to
> seperate the two runs counter to the aim of improving the ease of
> understanding of the script.
> 
> Obviously making the system multi language dramatically increases its 
appeal
> to a larger audience - thus satisfying 1 above but I feel that 2 will
> suffer.
> 
> I am thinking that at least in the short term a seperate offshoot for 
the
> multi-language version might be appropriate until I am convinced we 
will not
> be compromising the system with respect to 2.
> 
> I will upload the current state of the system to the CVS and yes you 
will
> need to set up an account.with sourceforge and let me know you 
username so I
> can add you to the developers with permissions to upload to CVS.
> 
> I will maintain and apply improvements to the logic/functionality in 
the CVS
> multi-language version to the english version and vice-versa. It may 
become
> impossible for me to keep up with this in the longer term but lets 
see how
> we go.
> 
> Phil
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-
url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 
> 

-- 

Re: [Web-erp-developers] Language

[Daintree F. <p.d...@xt...>]

Hani,

Readability is fundamental and critical to me because:

1. I would like it to be accessible to as many people as possible.
2. I would like it to be easy for developers to make mods to suit any given
business requirement.

In my opinion - and I realise this is contrary to accepted programming
principles - the text of what is output adds context to the logic - to
seperate the two runs counter to the aim of improving the ease of
understanding of the script.

Obviously making the system multi language dramatically increases its appeal
to a larger audience - thus satisfying 1 above but I feel that 2 will
suffer.

I am thinking that at least in the short term a seperate offshoot for the
multi-language version might be appropriate until I am convinced we will not
be compromising the system with respect to 2.

I will upload the current state of the system to the CVS and yes you will
need to set up an account.with sourceforge and let me know you username so I
can add you to the developers with permissions to upload to CVS.

I will maintain and apply improvements to the logic/functionality in the CVS
multi-language version to the english version and vice-versa. It may become
impossible for me to keep up with this in the longer term but lets see how
we go.

Phil

Re: [Web-erp-developers] Language

[Hani N. <ha...@na...>]

Hi 

With regards to readability, in my opinion what makes the code
less readable is the mixing of php code and html output. I think 
this is one area we could improve, and it can be done in small steps.

One such thing would be to use of a helper class to display tables.
We can then start changing the way we generate tables, a few pages
at a time, since this is a presentation (per page) issue. 

Overall, I think readability is not a priority 1 issue, it will come 
with time.

With regards to CVS. If you would like some help with it let me know
I guess I also need to create a source forge account and join the
group (is that how it works at SourceForge?). 

I also want to give a go at starting Localisation and so we need to 
figure out how not to over-write each others work. I plan to do a 
few pages at a time, I wont be changing any logic, just the string
outputs, so it should not affect anyone, but it does mean that we 
dont want to be changing the same files at the same time :)  

It would be nice if we used the bulletin boards provided at 
SourceForge. That way we have a permanent record and
more importantly other people will be able to see that this is 
an active project.


Regards,
Hani



> OK - I bow to the pros :-)
> 
> Just tell me you found it difficult to get into these scripts.
> If so, then we'll transform them into easier to read ones?
> 
> I agree, the style-sheet is a "no brainer" and does not impact on
> readability to me. Templates are another issue.
> 
> Phil
> 
> ----- Original Message -----
> From: "Sherif Omar" <sh...@ky...>
> To: "Phil Daintree" <ph...@du...>; "Web ERP Developers"
> <Web...@li...>
> Sent: Thursday, July 31, 2003 9:51 PM
> Subject: Re: [Web-erp-developers] Language
> 
> 
> > Hi Guys,
> >
> > I have quite a bit of experience in localization, so allow for me 
to weigh
> > in on this issue.
> >
> > * The scripting solution sounds good, however I have never seen 
such a
> > solution being used, there is WAY too much fine-tuning and 
modifcation of
> > strings for each language to make automation a workable solution. 
There
> are
> > just too many special cases. In this way we are treating the 
process of
> > making the system localizable as an annoyance that we deal with 
after
> > coding, while it should be a central theme.
> >
> > * I do not see readability of strings in code as a major issue at 
all -
> the
> > best designed user interfaces are totally separated from the code 
(as in
> > most non-web languages). I strongly advocate the use of templates 
and
> styles
> > as they cut down on maintainance greatly - otherwise any user 
interface
> > customization will have to be done on every page, for example, if 
your
> > customer wants green table borders, you have to create a new copy 
of the
> > program specifically for them. With templates you can just create 
a new
> > "skin" with all the customer's preferences.
> >
> > * Having separate copies of the code, one for each language, 
sounds quite
> > drastic. In this way too, users cannot switch which language they 
are
> using.
> >
> > * Translators are generally non-technical people. Asking them to 
run
> scripts
> > and logging onto different urls cannot be a pretty picture.
> >
> > * Fixing string issues will be a nightmare. In your localized 
file, how do
> > you know which localized string refers to which english string ?
> >
> > regards
> > Sherif
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites 
including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-
url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 
> 

-- 

Re: [Web-erp-developers] Language

[Daintree F. <p.d...@xt...>]

OK - I bow to the pros :-)

Just tell me you found it difficult to get into these scripts.
If so, then we'll transform them into easier to read ones?

I agree, the style-sheet is a "no brainer" and does not impact on
readability to me. Templates are another issue.

Phil

----- Original Message -----
From: "Sherif Omar" <sh...@ky...>
To: "Phil Daintree" <ph...@du...>; "Web ERP Developers"
<Web...@li...>
Sent: Thursday, July 31, 2003 9:51 PM
Subject: Re: [Web-erp-developers] Language


> Hi Guys,
>
> I have quite a bit of experience in localization, so allow for me to weigh
> in on this issue.
>
> * The scripting solution sounds good, however I have never seen such a
> solution being used, there is WAY too much fine-tuning and modifcation of
> strings for each language to make automation a workable solution. There
are
> just too many special cases. In this way we are treating the process of
> making the system localizable as an annoyance that we deal with after
> coding, while it should be a central theme.
>
> * I do not see readability of strings in code as a major issue at all -
the
> best designed user interfaces are totally separated from the code (as in
> most non-web languages). I strongly advocate the use of templates and
styles
> as they cut down on maintainance greatly - otherwise any user interface
> customization will have to be done on every page, for example, if your
> customer wants green table borders, you have to create a new copy of the
> program specifically for them. With templates you can just create a new
> "skin" with all the customer's preferences.
>
> * Having separate copies of the code, one for each language, sounds quite
> drastic. In this way too, users cannot switch which language they are
using.
>
> * Translators are generally non-technical people. Asking them to run
scripts
> and logging onto different urls cannot be a pretty picture.
>
> * Fixing string issues will be a nightmare. In your localized file, how do
> you know which localized string refers to which english string ?
>
> regards
> Sherif
>

Re: [Web-erp-developers] CVS

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

Yeah you are right I will put up the latest this weekend. I've never used it
before but I will figure it out!

Phil
----- Original Message -----
From: "Sherif Omar" <sh...@ky...>
To: "Web ERP Developers" <Web...@li...>
Sent: Friday, August 01, 2003 12:06 AM
Subject: [Web-erp-developers] CVS


> Hi Guys,
>
> I think it's probably a good time to setup weberp in CVS to better manage
> the changes we're all making / going to make.
>
> cheers
> Sherif
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

[Web-erp-developers] CVS

[Sherif O. <sh...@ky...>]

Hi Guys,

I think it's probably a good time to setup weberp in CVS to better manage
the changes we're all making / going to make.

cheers
Sherif

Re: [Web-erp-developers] Language

[Sherif O. <sh...@ky...>]

Hi Guys,

I have quite a bit of experience in localization, so allow for me to weigh
in on this issue.

* The scripting solution sounds good, however I have never seen such a
solution being used, there is WAY too much fine-tuning and modifcation of
strings for each language to make automation a workable solution. There are
just too many special cases. In this way we are treating the process of
making the system localizable as an annoyance that we deal with after
coding, while it should be a central theme.

* I do not see readability of strings in code as a major issue at all - the
best designed user interfaces are totally separated from the code (as in
most non-web languages). I strongly advocate the use of templates and styles
as they cut down on maintainance greatly - otherwise any user interface
customization will have to be done on every page, for example, if your
customer wants green table borders, you have to create a new copy of the
program specifically for them. With templates you can just create a new
"skin" with all the customer's preferences.

* Having separate copies of the code, one for each language, sounds quite
drastic. In this way too, users cannot switch which language they are using.

* Translators are generally non-technical people. Asking them to run scripts
and logging onto different urls cannot be a pretty picture.

* Fixing string issues will be a nightmare. In your localized file, how do
you know which localized string refers to which english string ?

regards
Sherif

----- Original Message ----- 
From: "Phil Daintree" <ph...@du...>
To: "Web ERP Developers" <Web...@li...>
Sent: Thursday, July 31, 2003 3:25 AM
Subject: [Web-erp-developers] Language


> Hi Hani,
>
> Please to make your aquaintance at least over email.
>
> The language conversion parsing script would be pretty simple taking three
> arguments:
> - the file to be parsed and strings substituted
> - the file where the subsitute strings come from mapped to the english
> string in the current version.
> - the directory where the new file of the same name as the first argument
> should be put
>
> With each build of the system the process script would run as part of the
> script that creates the archive - ie before the archive is built.
>
> The language conversion file would just become a whole series of:
>
> "UTILITY PAGE That sets up a new  blank company record if not already
> existing", "lanuage equivalent of UTILITY PAGE That sets up a new blank
> company record if not already existing"
>
> read the whole language file into an array and work through each string in
> the file looking for it in the English and making a new file as was
> replacing all strings found in the language file with the language
> equivalent string.
>
> The advantages are:
> - Readability
> - No overhead to running multi-language ie there is less to parse for the
> web server no conditional includes depending on an additional SESSION
> variable for language for users. Way simpler - in my view ;-)
>
> I think both of these above are serious considerations.
>
> The downers are:
> - maintenance of the language files - we have this in any event. -
> modification of strings in the english version would need to be reflected
in
> the language files.
> - it may take 2-3 mins to run the script to make the language version(s)
> (Whoa!)
> - extra hd space on servers running multiple languages - with a complete
set
> of scripts for each language. (Not much though cos the system is pretty
> lean)
> - there would a seperate URL base directory for each language. No overhead
> on the system figuring out what language to use with conditional includes.
> This may actually be a plus?
>
> Your point about templates is interesting - I am not a fan of templates
> because of the readability thing! Its another level of absraction which
from
> a purists (computer science) perspective is beautiful but my experience
has
> been unpleasant untangling such applications. Are you finding this system
> hard to get to know because of it ? Sherif never answered that question so
I
> guess maybe it is?? It's very hard to guage for me since I wrote it.
> However, I don't find it that difficult to "get into" scripts that I did
and
> forgot over a year ago.
>
> The use of functions and includes is also minimised - although there are a
> few includes now. I don't believe there is masses of duplication though
and
> what little there is ensures everything is together and 12 or more files
are
> not required to be open simultaneously to figure out a single script. I
may
> be way off track, but this may explain a lot of perhaps unorthodox coding.
>
> I will have a crack at a parser/string substituaion script as described
> above - it sounds like a perl job really but more comfy with PHP now.
>
> Phil
>
> ----- Original Message -----
> From: "Hani Naguib" <ha...@na...>
> To: <Web...@li...>
> Sent: Thursday, July 31, 2003 11:01 AM
> Subject: Re: [Web-erp-developers] Re: Congratulations
>
>
> > Hi my name is Hani and I work with Sherif.
> >
> > I think that separate language files is a better approach. The way I
> > usually deal with it is to create a general language file and then
> > files spefic to a page. This approach allows for the language to be
> > changed dynamically and supports different users using different
> > languages. I split them into files (as opposed to a single huge
> > language file) to make it more managable and I also don't need to load
> > all strings for each and every page.
> >
> > In this approach a page that has multilingual support must include a
> > lang.inc file such as this:
> >
> > <?php
> >     ob_start();
> >     $lang = "en";
> >     //include ($lang . "/General.inc");
> >     include ("ar/General.inc");
> >
> >     $base = basename($_SERVER['SCRIPT_FILENAME']);
> >     $lFile =  $lang . "/" . substr($base,0,strlen($base)-
> > 3) . "inc" ;
> >     include ($lFile);
> > ?>
> >
> > In this example the language is set to "en", in a realistic system this
> > value would be obtained from the users preference (probably stored in
> > the session).
> >
> > What the script above does is simply load up $lang/General.inc and
> > another file whose name matches the page being requested for example
> > $lang/Z_CreateCompany.inc
> >
> > The actual language files would look something like this:
> >
> > <?php
> >
> > // Z_CreateCompanny.php
> >     $str_CreateCompanyTitle = ;
> >
> >     $str_CreateCompanyError1 = "An existing company record is set
> > up already. No alterations have been made";
> >
> >     $str_CreateCompanyMsg1 = "Company record is now available for
> > modification by clicking ";
> >     $str_CreateCompanyMsg2 = "this link";
> >
> > ?>
> >
> >
> > I see why you are worried about readability, but I think that going the
> > way of 'semi-automatic' translations will only complicate things.
> > You will have to spend a substantial amount of time writting a parser
> > etc. Given that you dont use templates your pages already suffer from
> > a lack of readability.
> >
> > Explicit localisation also has the advantage of being able to deal
> > with special cases in a more structure way.
> >
> > Having said that, it would be interresting to see how well this semi-
> > automatic approach works.
> >
> >
> >
> > > Unfortunately, all i know is english, and I'm pretty terrible at
> > that.
> > > Phil, sorry I havn't gotten the PDF Files completed yet, I have been
> > > dealing with an Oracle headache, obtained my RedHat Linux
> > Certification,
> > > and went to Boston on vacation, its been a hell of a month.  I had
> > some
> > > of the conversion already done, I will hop to it right now though,
> > > barring anymore Oracle issues.
> > >
> > > Chris Bice
> > >
> > > On Wed, 2003-07-30 at 00:57, Daintree Family wrote:
> > > > Hi Alvaro,
> > > >
> > > > I am sure that a Spanish version would go down really well!
> > > >
> > > > Sherif Omar has expressed a willingness to make the system multi
> > language
> > > > capable, I am only concerned that the readability of the system
> > will be
> > > > compromised by changing all the text in echo statements and print
> > statements
> > > > to less understandable (to developers in any language) variable
> > names. This
> > > > may be a necessary compromise to make the system available to
> > users in any
> > > > language.
> > > >
> > > > Once Sherif, who I think works for an Egyptian software company
> > has donated
> > > > his work back to the community, this will allow a seperate include
> > file to
> > > > contain all the translated text, modifications to the underlying
> > scripts
> > > > will then not require additional translation as they will refer to
> > the
> > > > variables in the include file.
> > > >
> > > > Translating the system script by script would effectively make a
> > seperate
> > > > system where improvements in one language's version would not be
> > readily
> > > > transferable to another language without a re-write of the whole
> > script in
> > > > the other languages.
> > > >
> > > > One thought that could retain script readabliity, is to make a
> > file that
> > > > maps the strings in English as they are to the language to be
> > changed to,
> > > > creation of the language version could then be automatically
> > created by
> > > > running the files through a string substitution script that takes
> > the file
> > > > name as an argument and the name of the string substitution file
> > ie the file
> > > > that maps the english string to the language string. The output
> > would be a
> > > > language version of the script. This would make the scripts much
> > more
> > > > readable to developers (in the language of chocie) looking at the
> > resulting
> > > > scripts. Using this approach new language versions could be
> > produced
> > > > automatically provided the text of the english version strings is
> > not
> > > > changed ;-) or the language string maps all changed at the same
> > time. It
> > > > would also allow conversion back from the language version to the
> > english
> > > > version.
> > > >
> > > > I could write the string substiution script but would need serious
> > help with
> > > > the englsih string extraction from every script and the translated
> > strings
> > > > :-(
> > > >
> > > > Users of the same system could work in different languages by
> > pointing the
> > > > language versions at the same database from the config.php file -
> > and the
> > > > web server URL for the alternate languages being different.
> > > >
> > > > Comments always appreciated - Sherif ?
> > > >
> > > > Serial number tracking would be good but I have not given this
> > much thought
> > > > yet.
> > > >
> > > > Phil
> > > >
> > > > ----- Original Message -----
> > > > From: "Alvaro Ventura" <int...@us...>
> > > > To: <dai...@us...>
> > > > Sent: Wednesday, July 30, 2003 5:14 AM
> > > > Subject: Congratulations
> > > >
> > > >
> > > > > Hello!
> > > > > My name is Alvaro Ventura (from Mexico)
> > > > > last week I downloaded the web-erp.
> > > > > Have some troubles but finally is run now.
> > > > > Do you like put your web-erp in spanish?
> > > > > I could be help you.
> > > > > I think its a good idea for spanish users, here in Mexico, PHP
> > > > > is in progress and I Think is a good moment to begin with this
> > > > > great proyect.
> > > > >
> > > > > Do you Think, integrate a serial number tracking?
> > > > > Could be a full solution in the web-erp proyect.
> > > > >
> > > > > best regards.
> > > > >
> > > > > PD Congratualtions ! web-erp looks a serious ERP
> > > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email sponsored by: Free pre-built ASP.NET sites
> > including
> > > > Data Reports, E-commerce, Portals, and Forums are available now.
> > > > Download today and enter to win an XBOX or Visual Studio .NET.
> > > > http://aspnet.click-
> > url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > > > _______________________________________________
> > > > Web-erp-developers mailing list
> > > > Web...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: Free pre-built ASP.NET sites
> > including
> > > Data Reports, E-commerce, Portals, and Forums are available now.
> > > Download today and enter to win an XBOX or Visual Studio .NET.
> > > http://aspnet.click-
> > url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > > _______________________________________________
> > > Web-erp-developers mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > >
> > >
> >
> > --
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> >
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

[Web-erp-developers] Language

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

Hi Hani,

Please to make your aquaintance at least over email.

The language conversion parsing script would be pretty simple taking three
arguments:
- the file to be parsed and strings substituted
- the file where the subsitute strings come from mapped to the english
string in the current version.
- the directory where the new file of the same name as the first argument
should be put

With each build of the system the process script would run as part of the
script that creates the archive - ie before the archive is built.

The language conversion file would just become a whole series of:

"UTILITY PAGE That sets up a new  blank company record if not already
existing", "lanuage equivalent of UTILITY PAGE That sets up a new blank
company record if not already existing"

read the whole language file into an array and work through each string in
the file looking for it in the English and making a new file as was
replacing all strings found in the language file with the language
equivalent string.

The advantages are:
- Readability
- No overhead to running multi-language ie there is less to parse for the
web server no conditional includes depending on an additional SESSION
variable for language for users. Way simpler - in my view ;-)

I think both of these above are serious considerations.

The downers are:
- maintenance of the language files - we have this in any event. -
modification of strings in the english version would need to be reflected in
the language files.
- it may take 2-3 mins to run the script to make the language version(s)
(Whoa!)
- extra hd space on servers running multiple languages - with a complete set
of scripts for each language. (Not much though cos the system is pretty
lean)
- there would a seperate URL base directory for each language. No overhead
on the system figuring out what language to use with conditional includes.
This may actually be a plus?

Your point about templates is interesting - I am not a fan of templates
because of the readability thing! Its another level of absraction which from
a purists (computer science) perspective is beautiful but my experience has
been unpleasant untangling such applications. Are you finding this system
hard to get to know because of it ? Sherif never answered that question so I
guess maybe it is?? It's very hard to guage for me since I wrote it.
However, I don't find it that difficult to "get into" scripts that I did and
forgot over a year ago.

The use of functions and includes is also minimised - although there are a
few includes now. I don't believe there is masses of duplication though and
what little there is ensures everything is together and 12 or more files are
not required to be open simultaneously to figure out a single script. I may
be way off track, but this may explain a lot of perhaps unorthodox coding.

I will have a crack at a parser/string substituaion script as described
above - it sounds like a perl job really but more comfy with PHP now.

Phil

----- Original Message -----
From: "Hani Naguib" <ha...@na...>
To: <Web...@li...>
Sent: Thursday, July 31, 2003 11:01 AM
Subject: Re: [Web-erp-developers] Re: Congratulations


> Hi my name is Hani and I work with Sherif.
>
> I think that separate language files is a better approach. The way I
> usually deal with it is to create a general language file and then
> files spefic to a page. This approach allows for the language to be
> changed dynamically and supports different users using different
> languages. I split them into files (as opposed to a single huge
> language file) to make it more managable and I also don't need to load
> all strings for each and every page.
>
> In this approach a page that has multilingual support must include a
> lang.inc file such as this:
>
> <?php
>     ob_start();
>     $lang = "en";
>     //include ($lang . "/General.inc");
>     include ("ar/General.inc");
>
>     $base = basename($_SERVER['SCRIPT_FILENAME']);
>     $lFile =  $lang . "/" . substr($base,0,strlen($base)-
> 3) . "inc" ;
>     include ($lFile);
> ?>
>
> In this example the language is set to "en", in a realistic system this
> value would be obtained from the users preference (probably stored in
> the session).
>
> What the script above does is simply load up $lang/General.inc and
> another file whose name matches the page being requested for example
> $lang/Z_CreateCompany.inc
>
> The actual language files would look something like this:
>
> <?php
>
> // Z_CreateCompanny.php
>     $str_CreateCompanyTitle = ;
>
>     $str_CreateCompanyError1 = "An existing company record is set
> up already. No alterations have been made";
>
>     $str_CreateCompanyMsg1 = "Company record is now available for
> modification by clicking ";
>     $str_CreateCompanyMsg2 = "this link";
>
> ?>
>
>
> I see why you are worried about readability, but I think that going the
> way of 'semi-automatic' translations will only complicate things.
> You will have to spend a substantial amount of time writting a parser
> etc. Given that you dont use templates your pages already suffer from
> a lack of readability.
>
> Explicit localisation also has the advantage of being able to deal
> with special cases in a more structure way.
>
> Having said that, it would be interresting to see how well this semi-
> automatic approach works.
>
>
>
> > Unfortunately, all i know is english, and I'm pretty terrible at
> that.
> > Phil, sorry I havn't gotten the PDF Files completed yet, I have been
> > dealing with an Oracle headache, obtained my RedHat Linux
> Certification,
> > and went to Boston on vacation, its been a hell of a month.  I had
> some
> > of the conversion already done, I will hop to it right now though,
> > barring anymore Oracle issues.
> >
> > Chris Bice
> >
> > On Wed, 2003-07-30 at 00:57, Daintree Family wrote:
> > > Hi Alvaro,
> > >
> > > I am sure that a Spanish version would go down really well!
> > >
> > > Sherif Omar has expressed a willingness to make the system multi
> language
> > > capable, I am only concerned that the readability of the system
> will be
> > > compromised by changing all the text in echo statements and print
> statements
> > > to less understandable (to developers in any language) variable
> names. This
> > > may be a necessary compromise to make the system available to
> users in any
> > > language.
> > >
> > > Once Sherif, who I think works for an Egyptian software company
> has donated
> > > his work back to the community, this will allow a seperate include
> file to
> > > contain all the translated text, modifications to the underlying
> scripts
> > > will then not require additional translation as they will refer to
> the
> > > variables in the include file.
> > >
> > > Translating the system script by script would effectively make a
> seperate
> > > system where improvements in one language's version would not be
> readily
> > > transferable to another language without a re-write of the whole
> script in
> > > the other languages.
> > >
> > > One thought that could retain script readabliity, is to make a
> file that
> > > maps the strings in English as they are to the language to be
> changed to,
> > > creation of the language version could then be automatically
> created by
> > > running the files through a string substitution script that takes
> the file
> > > name as an argument and the name of the string substitution file
> ie the file
> > > that maps the english string to the language string. The output
> would be a
> > > language version of the script. This would make the scripts much
> more
> > > readable to developers (in the language of chocie) looking at the
> resulting
> > > scripts. Using this approach new language versions could be
> produced
> > > automatically provided the text of the english version strings is
> not
> > > changed ;-) or the language string maps all changed at the same
> time. It
> > > would also allow conversion back from the language version to the
> english
> > > version.
> > >
> > > I could write the string substiution script but would need serious
> help with
> > > the englsih string extraction from every script and the translated
> strings
> > > :-(
> > >
> > > Users of the same system could work in different languages by
> pointing the
> > > language versions at the same database from the config.php file -
> and the
> > > web server URL for the alternate languages being different.
> > >
> > > Comments always appreciated - Sherif ?
> > >
> > > Serial number tracking would be good but I have not given this
> much thought
> > > yet.
> > >
> > > Phil
> > >
> > > ----- Original Message -----
> > > From: "Alvaro Ventura" <int...@us...>
> > > To: <dai...@us...>
> > > Sent: Wednesday, July 30, 2003 5:14 AM
> > > Subject: Congratulations
> > >
> > >
> > > > Hello!
> > > > My name is Alvaro Ventura (from Mexico)
> > > > last week I downloaded the web-erp.
> > > > Have some troubles but finally is run now.
> > > > Do you like put your web-erp in spanish?
> > > > I could be help you.
> > > > I think its a good idea for spanish users, here in Mexico, PHP
> > > > is in progress and I Think is a good moment to begin with this
> > > > great proyect.
> > > >
> > > > Do you Think, integrate a serial number tracking?
> > > > Could be a full solution in the web-erp proyect.
> > > >
> > > > best regards.
> > > >
> > > > PD Congratualtions ! web-erp looks a serious ERP
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: Free pre-built ASP.NET sites
> including
> > > Data Reports, E-commerce, Portals, and Forums are available now.
> > > Download today and enter to win an XBOX or Visual Studio .NET.
> > > http://aspnet.click-
> url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > > _______________________________________________
> > > Web-erp-developers mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites
> including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-
> url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> >
>
> --
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [Web-erp-developers] Re: Congratulations

[Hani N. <ha...@na...>]

Hi my name is Hani and I work with Sherif.

I think that separate language files is a better approach. The way I 
usually deal with it is to create a general language file and then
files spefic to a page. This approach allows for the language to be
changed dynamically and supports different users using different 
languages. I split them into files (as opposed to a single huge 
language file) to make it more managable and I also don't need to load 
all strings for each and every page.

In this approach a page that has multilingual support must include a 
lang.inc file such as this:

<?php
    ob_start();
    $lang = "en";
    //include ($lang . "/General.inc");
    include ("ar/General.inc");
    
    $base = basename($_SERVER['SCRIPT_FILENAME']); 
    $lFile =  $lang . "/" . substr($base,0,strlen($base)-
3) . "inc" ;
    include ($lFile);
?>  

In this example the language is set to "en", in a realistic system this
value would be obtained from the users preference (probably stored in
the session).

What the script above does is simply load up $lang/General.inc and 
another file whose name matches the page being requested for example
$lang/Z_CreateCompany.inc

The actual language files would look something like this:

<?php 

// Z_CreateCompanny.php
    $str_CreateCompanyTitle = "UTILITY PAGE That sets up a new 
blank company record if not already existing";

    $str_CreateCompanyError1 = "An existing company record is set 
up already. No alterations have been made";
    
    $str_CreateCompanyMsg1 = "Company record is now available for 
modification by clicking ";
    $str_CreateCompanyMsg2 = "this link";

?>


I see why you are worried about readability, but I think that going the
way of 'semi-automatic' translations will only complicate things.
You will have to spend a substantial amount of time writting a parser 
etc. Given that you dont use templates your pages already suffer from 
a lack of readability.

Explicit localisation also has the advantage of being able to deal
with special cases in a more structure way.

Having said that, it would be interresting to see how well this semi-
automatic approach works. 



> Unfortunately, all i know is english, and I'm pretty terrible at 
that. 
> Phil, sorry I havn't gotten the PDF Files completed yet, I have been
> dealing with an Oracle headache, obtained my RedHat Linux 
Certification,
> and went to Boston on vacation, its been a hell of a month.  I had 
some
> of the conversion already done, I will hop to it right now though,
> barring anymore Oracle issues.
> 
> Chris Bice
> 
> On Wed, 2003-07-30 at 00:57, Daintree Family wrote:
> > Hi Alvaro,
> > 
> > I am sure that a Spanish version would go down really well!
> > 
> > Sherif Omar has expressed a willingness to make the system multi 
language
> > capable, I am only concerned that the readability of the system 
will be
> > compromised by changing all the text in echo statements and print 
statements
> > to less understandable (to developers in any language) variable 
names. This
> > may be a necessary compromise to make the system available to 
users in any
> > language.
> > 
> > Once Sherif, who I think works for an Egyptian software company 
has donated
> > his work back to the community, this will allow a seperate include 
file to
> > contain all the translated text, modifications to the underlying 
scripts
> > will then not require additional translation as they will refer to 
the
> > variables in the include file.
> > 
> > Translating the system script by script would effectively make a 
seperate
> > system where improvements in one language's version would not be 
readily
> > transferable to another language without a re-write of the whole 
script in
> > the other languages.
> > 
> > One thought that could retain script readabliity, is to make a 
file that
> > maps the strings in English as they are to the language to be 
changed to,
> > creation of the language version could then be automatically 
created by
> > running the files through a string substitution script that takes 
the file
> > name as an argument and the name of the string substitution file 
ie the file
> > that maps the english string to the language string. The output 
would be a
> > language version of the script. This would make the scripts much 
more
> > readable to developers (in the language of chocie) looking at the 
resulting
> > scripts. Using this approach new language versions could be 
produced
> > automatically provided the text of the english version strings is 
not
> > changed ;-) or the language string maps all changed at the same 
time. It
> > would also allow conversion back from the language version to the 
english
> > version.
> > 
> > I could write the string substiution script but would need serious 
help with
> > the englsih string extraction from every script and the translated 
strings
> > :-(
> > 
> > Users of the same system could work in different languages by 
pointing the
> > language versions at the same database from the config.php file - 
and the
> > web server URL for the alternate languages being different.
> > 
> > Comments always appreciated - Sherif ?
> > 
> > Serial number tracking would be good but I have not given this 
much thought
> > yet.
> > 
> > Phil
> > 
> > ----- Original Message -----
> > From: "Alvaro Ventura" <int...@us...>
> > To: <dai...@us...>
> > Sent: Wednesday, July 30, 2003 5:14 AM
> > Subject: Congratulations
> > 
> > 
> > > Hello!
> > > My name is Alvaro Ventura (from Mexico)
> > > last week I downloaded the web-erp.
> > > Have some troubles but finally is run now.
> > > Do you like put your web-erp in spanish?
> > > I could be help you.
> > > I think its a good idea for spanish users, here in Mexico, PHP
> > > is in progress and I Think is a good moment to begin with this
> > > great proyect.
> > >
> > > Do you Think, integrate a serial number tracking?
> > > Could be a full solution in the web-erp proyect.
> > >
> > > best regards.
> > >
> > > PD Congratualtions ! web-erp looks a serious ERP
> > >
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites 
including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-
url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites 
including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-
url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> 
> 

-- 

Re: [Web-erp-developers] Re: Congratulations

[Sherif O. <sh...@ky...>]

Hani Naguib (also from KylieTech) is now working on web-erp instead of me.
He'll reply shortly re. localization.

cheers
Sherif

----- Original Message ----- 
From: "Chris Bice" <cb...@en...>
To: "Daintree Family" <p.d...@xt...>
Cc: "Web-ERP Dewvelopers" <Web...@li...>;
"Alvaro Ventura" <int...@us...>
Sent: Wednesday, July 30, 2003 8:46 PM
Subject: Re: [Web-erp-developers] Re: Congratulations


> Unfortunately, all i know is english, and I'm pretty terrible at that.
> Phil, sorry I havn't gotten the PDF Files completed yet, I have been
> dealing with an Oracle headache, obtained my RedHat Linux Certification,
> and went to Boston on vacation, its been a hell of a month.  I had some
> of the conversion already done, I will hop to it right now though,
> barring anymore Oracle issues.
>
> Chris Bice
>
> On Wed, 2003-07-30 at 00:57, Daintree Family wrote:
> > Hi Alvaro,
> >
> > I am sure that a Spanish version would go down really well!
> >
> > Sherif Omar has expressed a willingness to make the system multi
language
> > capable, I am only concerned that the readability of the system will be
> > compromised by changing all the text in echo statements and print
statements
> > to less understandable (to developers in any language) variable names.
This
> > may be a necessary compromise to make the system available to users in
any
> > language.
> >
> > Once Sherif, who I think works for an Egyptian software company has
donated
> > his work back to the community, this will allow a seperate include file
to
> > contain all the translated text, modifications to the underlying scripts
> > will then not require additional translation as they will refer to the
> > variables in the include file.
> >
> > Translating the system script by script would effectively make a
seperate
> > system where improvements in one language's version would not be readily
> > transferable to another language without a re-write of the whole script
in
> > the other languages.
> >
> > One thought that could retain script readabliity, is to make a file that
> > maps the strings in English as they are to the language to be changed
to,
> > creation of the language version could then be automatically created by
> > running the files through a string substitution script that takes the
file
> > name as an argument and the name of the string substitution file ie the
file
> > that maps the english string to the language string. The output would be
a
> > language version of the script. This would make the scripts much more
> > readable to developers (in the language of chocie) looking at the
resulting
> > scripts. Using this approach new language versions could be produced
> > automatically provided the text of the english version strings is not
> > changed ;-) or the language string maps all changed at the same time. It
> > would also allow conversion back from the language version to the
english
> > version.
> >
> > I could write the string substiution script but would need serious help
with
> > the englsih string extraction from every script and the translated
strings
> > :-(
> >
> > Users of the same system could work in different languages by pointing
the
> > language versions at the same database from the config.php file - and
the
> > web server URL for the alternate languages being different.
> >
> > Comments always appreciated - Sherif ?
> >
> > Serial number tracking would be good but I have not given this much
thought
> > yet.
> >
> > Phil
> >
> > ----- Original Message -----
> > From: "Alvaro Ventura" <int...@us...>
> > To: <dai...@us...>
> > Sent: Wednesday, July 30, 2003 5:14 AM
> > Subject: Congratulations
> >
> >
> > > Hello!
> > > My name is Alvaro Ventura (from Mexico)
> > > last week I downloaded the web-erp.
> > > Have some troubles but finally is run now.
> > > Do you like put your web-erp in spanish?
> > > I could be help you.
> > > I think its a good idea for spanish users, here in Mexico, PHP
> > > is in progress and I Think is a good moment to begin with this
> > > great proyect.
> > >
> > > Do you Think, integrate a serial number tracking?
> > > Could be a full solution in the web-erp proyect.
> > >
> > > best regards.
> > >
> > > PD Congratualtions ! web-erp looks a serious ERP
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> >
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [Web-erp-developers] Re: Congratulations

[Chris B. <cb...@en...>]

Unfortunately, all i know is english, and I'm pretty terrible at that. 
Phil, sorry I havn't gotten the PDF Files completed yet, I have been
dealing with an Oracle headache, obtained my RedHat Linux Certification,
and went to Boston on vacation, its been a hell of a month.  I had some
of the conversion already done, I will hop to it right now though,
barring anymore Oracle issues.

Chris Bice

On Wed, 2003-07-30 at 00:57, Daintree Family wrote:
> Hi Alvaro,
> 
> I am sure that a Spanish version would go down really well!
> 
> Sherif Omar has expressed a willingness to make the system multi language
> capable, I am only concerned that the readability of the system will be
> compromised by changing all the text in echo statements and print statements
> to less understandable (to developers in any language) variable names. This
> may be a necessary compromise to make the system available to users in any
> language.
> 
> Once Sherif, who I think works for an Egyptian software company has donated
> his work back to the community, this will allow a seperate include file to
> contain all the translated text, modifications to the underlying scripts
> will then not require additional translation as they will refer to the
> variables in the include file.
> 
> Translating the system script by script would effectively make a seperate
> system where improvements in one language's version would not be readily
> transferable to another language without a re-write of the whole script in
> the other languages.
> 
> One thought that could retain script readabliity, is to make a file that
> maps the strings in English as they are to the language to be changed to,
> creation of the language version could then be automatically created by
> running the files through a string substitution script that takes the file
> name as an argument and the name of the string substitution file ie the file
> that maps the english string to the language string. The output would be a
> language version of the script. This would make the scripts much more
> readable to developers (in the language of chocie) looking at the resulting
> scripts. Using this approach new language versions could be produced
> automatically provided the text of the english version strings is not
> changed ;-) or the language string maps all changed at the same time. It
> would also allow conversion back from the language version to the english
> version.
> 
> I could write the string substiution script but would need serious help with
> the englsih string extraction from every script and the translated strings
> :-(
> 
> Users of the same system could work in different languages by pointing the
> language versions at the same database from the config.php file - and the
> web server URL for the alternate languages being different.
> 
> Comments always appreciated - Sherif ?
> 
> Serial number tracking would be good but I have not given this much thought
> yet.
> 
> Phil
> 
> ----- Original Message -----
> From: "Alvaro Ventura" <int...@us...>
> To: <dai...@us...>
> Sent: Wednesday, July 30, 2003 5:14 AM
> Subject: Congratulations
> 
> 
> > Hello!
> > My name is Alvaro Ventura (from Mexico)
> > last week I downloaded the web-erp.
> > Have some troubles but finally is run now.
> > Do you like put your web-erp in spanish?
> > I could be help you.
> > I think its a good idea for spanish users, here in Mexico, PHP
> > is in progress and I Think is a good moment to begin with this
> > great proyect.
> >
> > Do you Think, integrate a serial number tracking?
> > Could be a full solution in the web-erp proyect.
> >
> > best regards.
> >
> > PD Congratualtions ! web-erp looks a serious ERP
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers