I work with Act since a long time and have in all past versions struggled with incompatibilities of "international versions" against the plain US version of Act. In a recent case a very desirable addon product (tested great with the US version) fails when used with
ACT! by Sage Premium 2008 (10.0) (ST Edition) Version 10.0.3.182, Hotfix 1
English (Europe)
and OS local settings set to: German (Germany)
The last setting is a MUST in Germany (but also for other European countries), as it defines the formatting of
Dates (tt.mm.yyyy), Currency (9.999,00 €) and decimal-point-is-comma - next to some further internals like sort-order of "Umlauts".
SAGE has taken care of this by generating some localized country versions and provides during installation of the English version
a setup question "where will this product be used?" and one answer option is "Europe". Installing this way Act and all internal options will run smoothly and accept the PCs localized settings without problems (IMHO so far)...
Unfortunately (most) Addon developers use only the original US version to code and test their applications.
They are not aware of the differences regarding the international versions, or they lack the necessary information how to make
the product "one-exe-fits-all" international ACT versions. Working for a global company we have had long time experience with those incompatibilities, so our internal SW dev policy guide says to always first check "local settings", "PC language", "database/SW language" and then provide the necessary adoptions (i.e. call to localized DLL names) within the coding.
Can someone tell me if there is a
documentation by SAGE that supports developers to write their addons for ALL Act versions?
Or. at least, gives them an overview what differences they have to look out for when "localizing" their product.
Definitively the best way - to avoid managing x different language EXE versions - would be the "one-exe-fits-all" approach.
Many thanks for your attention to this matter.
Martin Glueckmann
PS: We have currently a project for 45+ users where Act11 is chosen as basic app together with a US developed solution.
Main data entry must be done with that addon, if that is not working for Act English (Europe) the whole project is dead.
With Act US the custom entity addon runs perfect, but with our version
i.e. deleting a record from a subentity is impossible: "Wrong county processor" error...
plus several errors in other parts (showing wrong digits in num fields, foreseen Excel export bounces, etc).
..
Martin Glueckmann ACT since 1995 for 40+ user teams in Germany, Austria, Switzerland, Benelux
I don’t believe we currently have a document outlining internationalization / globalization / localization best practices for add-on developers, but I’ll take this as an opportunity to give you some key highlights:
ACT! supports standard .NET localization.
Satellite assemblies (localized resources) used are determined by the UI thread’s CurrentUICulture.So simply localizing the add-on and deploying appropriate satellite assemblies alongside should work.
CurrentCulture is used for date, number, etc… formatting as expected.
Here’s where there’s some specific ACT! variations to be aware of:
The currency symbol is driven by the ACT! database.The currency is stamped in the database at the time of database creation.
Decimal precision is determined and controlled by the field definition (Define Fields) in ACT!, which is user controlled.
Sorting in the product is determined (mostly) by the database collation.If the data is sorted client-side, it is OS determined (CurrentCulture above).
Xavier, can I just say that the currency stamp being fixed is annoying, but the language being fixed also at creation has been a significant issue for those who deal with users in different parts of the word since ACT! 7.0 ... You all have to use the same language version of ACT!
