Community
Showing results for 
Search instead for 
Do you mean 
Reply

Act premium V10 and Act premium Web V10

New Member
Posts: 2
Country: france

Act premium V10 and Act premium Web V10

Hello
 
I have  Act 2008 premium V10 (French version)
 
I would like to buy Act 2008 premium V10 WEB. But in france this version does not exist
 
Do you think that I can have Act 2008 premium WEB (English version) and Act 2008 premium (French version) ?
 
Where can I see screenshots of the web version and/or get a trial version ?
 
Thank for your answers
 
OG
Copper Contributor
Posts: 97
Country: USA

Re: Act premium V10 and Act premium Web V10

Hello,
 
Unfortunately you can't use a French ACT! product with an English version, or more specifically you can't share an ACT! database.  This is primarily due to currency... the French database is created with a Euro currency setting while English uses the dollar.  ACT! has a built-in check that will disallow an English application from connecting to a French database, and vice versa.
 
On the good side... ACT! is working on implementing their LDK (localization development kit) for the ACT! for Web product so you should see localized (French, German, Dutch, etc.) versions of ACT! for Web in the not-too-distant future.
 
jason
Jason Sellers
ACT! Engineer 2000-2007
Platinum Elite Contributor
Posts: 14,384
Country: Australia

Re: Act premium V10 and Act premium Web V10

If you need to use Web 10.0, you'll need to change all the systems to English at this time...
 
You'll also need to have the database marker changed which is a real pain, but the guys at www.crmaddon.com in Germany can do this if you need it
Copper Contributor
Posts: 97
Country: USA

Re: Act premium V10 and Act premium Web V10

Hi Mike,
 
Just wondering which "database marker" you're talking about... do you mean the Culture setting?
 
Thanks,
jason
Jason Sellers
ACT! Engineer 2000-2007
Platinum Elite Contributor
Posts: 14,384
Country: Australia

Re: Act premium V10 and Act premium Web V10

The database Language and Currency settings... see Help | About | Database Information - Database Settings Information and 6 or 7 lines down.
 
If ACT! is installed with the wrong setting and a database is created, you need to crack the SQL to change the setting if you want to change the regional setting in ACT!
 
A lot of Euro users unstalled US builds while waiting for local versions and need to have the db hacked to get it working when they get to switch to the correct local build.
 
It also prevents users in different countries to use ACT! in their local languages
 
Even allowing for the lack of currency conversion, I can't see a reason for tying the database to the language of ACT! it was created in.
 
This even applies to an ACT! 6.0 database created in one language... it can only be opened and updated by the same langauge build in the later version. With ACT! 6.0 you could open a database in FR, EN, GER, etc no matter how it was created. ACT! by Sage blocks this making it messy for a lot of inernational users...
Copper Contributor
Posts: 97
Country: USA

Re: Act premium V10 and Act premium Web V10

I still remember the day we made the decision to disallow cross-culture interactivity in v7+.  At the time I was against it but there are so many issues involved not only in engineering but also testing the multitude of combinations of operating system, database (SQL) and application culture settings that the business justification apparently just wasn't there.  The biggest engineering issue seemed to be trying to sync a database with product price settings amongst different currency values.
 
Also figure in the fact that Sage has a goal of sim-ship or simultaneous shipment of English along with localized versions.  This may never fully happen but it's getting much better.  The guys in the new Sage localisation centre in Dublin are doing a great job bringing in the release dates of localized products.
 
Anyway, what you're pointing out is that he'll have to use English for now.... then, when a French version of ACT! for Web is available, he'll have to get his database settings fixed to migrate his data.  Not that he has to get those settings fixed now.  Right?
 
Thanks for the clarification.
 
jason
Jason Sellers
ACT! Engineer 2000-2007
Platinum Elite Contributor
Posts: 14,384
Country: Australia

Re: Act premium V10 and Act premium Web V10

He'd need to get his db fixed now if he wanted to use Web... and change everything to English
 
The localisation has never been good with ACT! but it's more of a problem with Sage... they do things like convert items in the registry and field codes, creating issues for add-on developers. The Dublin guys don't seem to really get ACT!... ask any EU ACC.
 
They should just have a lang file with the text for the menus, help, tooltips, etc... all the UI. The engine should NOT be translated as any programmer can code with English names. This would allow them to produce local versions much faster or allow a US build to be used to a local ver is available. Just have the user define the currency on database creation (with default to the regional setting in Windows) till currency conversion is supported.
 
It's a common issue with US developers making this much harder than it needs to be and Sage's regionalisation seems to make this hard to fix.
Copper Contributor
Posts: 97
Country: USA

Re: Act premium V10 and Act premium Web V10

Ah yes, convert his current French db to English to be used by ACT! for Web... then back to French when the product is available... exactly.

Just a lang file with all the text for localization? I only wish it were that easy! ;-) ACT! has so many disparate resources in so many different formats (Windows Forms, database, 3rd party controls, installers, etc. etc.) that a simple text file for localization is simply not possible. In fact, to try and do something like that would slow ACT! down considerably.

However I do agree with your sentiment about US developers and their tendencies to eschew localization. ACT! does have examples of this. And the guys in Dublin probably are not ACT! experts as they were hired to localize an array of products across Sage. Not to mention that the business is pretty young and the people are still relatively new to Sage.

As for currency, it wouldn't be hard to let you choose on db creation but that wouldn't help collaboration/sync of the data, and I imagine it would generate more support calls and angry customers wanting to merge.

You're right about registry keys (for the most part) and database field names, they are not intended to be localized. Things like that are defects just like any other product defect.

Jason Sellers
ACT! Engineer 2000-2007
Platinum Elite Contributor
Posts: 14,384
Country: Australia

Re: Act premium V10 and Act premium Web V10

Re "disparate resources"... that's a programming design issue. However, it still doesn't explain the enforced localisation of the db nor the translation of the back-end
 
Re Dublin: localisation for accounting products is quite a different issue as accounting systems often need to be different in different countries because of changes to tax legislation. Sage need to realise that CRM users tend to be more global.
 
Re the choice of currency... understanding that a shared database can only pick one currency but allow sharing/sync by global users would be better than the current issue
 
I (and other int'l users) have been pointing out the probles with translating registry and database engine components for some time... the US developers say this is an an issue for Dublin, but the people in control of that do not make themseleves available to ACT! partners like the US guys sometimes do
Copper Contributor
Posts: 97
Country: USA

Re: Act premium V10 and Act premium Web V10

Disparate resources may in some cases be a programming design issue, but in this case more often than not it's a product management/3rd-party-component issue.
 
I'm not sure what you mean by "translation of the back-end."  ACT! does not translate any framework/sdk objects or database column names (only display names).  We did have problems with the OLE-DB provider at one point but I'm pretty sure that was fixed a while back.
 
As for the sharing/currency/sync issues: are you suggesting that sync/sharing should be allowed between databases of different currencies?  I think this is exactly what we were trying to avoid.  Wouldn't this introduce a HUGE testing/compatibility-matrix requirement?
 
While Dublin is responsible for the actual translation, the Scottsdale office is in charge of building the LDK (which defines which strings are to be translated).  We (oops, they) routinely submit internal defects to remove strings from public resources (and, hence, the LDK) if the string should never be translated.
 
If you have any specific translation problem examples I'd love to hear about them... I would love to try and get them addressed.
 
Thanks for the input... sounds like I should have been talking to you several years ago when we were designing the LDK... Smiley Wink
 
jason
 
Jason Sellers
ACT! Engineer 2000-2007