Visual dBASE 7

Meeting the Open Markets Challenge

  1. A common box in the European Union
  2. A strategy for multiple localizations
  3. Gradual levels for localization
  4. Markers for a winning strategy
  5. The right product to meet customer expectations

The rapid evolution of the IT market is shaking the grounds of the software industry.

Part of the user base is moving to the leading edge client/server Internet based tools. However, the larger numbers will take longer to move to the new paradigm -- probably years in some cases.

Both edges of the user base as described, plus all the intermediate levels, will ultimately embrace the opportunities of the InfoNet. New users facing new needs will accept the quantum leap required by their new tools. However, the majority will demand to capitalize on their current know-how and investment in data, tools and applications.

The coming 32-bit version of Visual dBASE is the best fitted development tool to facilitate the migration of the current dBASE user base to the InfoNet world.

While moving to an open world market, users are also demanding tools fitted to face both the international challenges and to meet the local specifics.

How can we face this challenge when increased competition affects sales revenues ?

The following is a modest attempt at outlining a path for a winning strategy.

A common box in the European Union

One step forward to take into account the basic fact : the European Union (EU) is a unified market : The box is not that of a consumer product anymore. The developer buying Visual dBASE 7 will have the details about specifications and features from the press and technical docs. In the box itself, there is an internationally recognised standard professional tool.

Just print on the box the short specs sheet and one marketing slogan in all the EU languages : The best tool for visual rapid development of business applications.

Contents of the box can be different for market specifics :

A strategy for multiple localizations

For partially localized locales : When the standard installation is performed, an English version is installed. The additional procedure copies the additional files for the language selected. The resulting installed product is thus partially localized into the selected locale.

Gradual levels for localization

The following levels can be identified :

The Borland Database Engine (BDE)

The BDE being common to most Borland products, a localized version may be available in most cases, the BDE having already been localized for Delphi, for instance. The same can be expected for the BDE Configuration Utility.

When available, the adequate BDE files for the EU locales can be included on the EU CD-ROM. Language drivers are not a concern, as they are all included for every locale anyway.

The VdB runtime virtual machine

The interface text, the service and error messages displayed at runtime are a most important element.

It is also a bare minimum requirement for successfully marketing a localized development product.

Current leading edge technology at Borland permits producing internationally enabled binaries common for all locales of a 32-bit products. The resources should then be accessible in the appropriate DLLs for translation.

The VdB Development Environment (Desktop)

Menu choices, designers and inspector text strings, wizard screens are some of the elements of a home in which a developer must feel comfortable in order to build the best business applications.

The developer today has the choice between many competing products. When the need to upgrade his existing applications to Windows 95, Windows NT and the Internet arrises, the dBASE developer will first look towards Visual dBASE.

However, the GUI and OO paradigms come with their own challenges. If the developer has to face the challenge to abandon his mother tongue in addition, he may choose the easy path and select another vendor altogether.

Again, the current Borland technology should make it possible to address DLL localization with minimum QA additional burden.

The deployment utility

Depending on the internal structure of the tool, this item could be divided in two parts :
  1. The deployment preparation tool, on the developer side.
  2. The application installation tool, on the user side.
Of course, localization of the latter is a more fundamental need than the former. The deployment tool setup being the last step of the production process, it could be considered to be less important in terms of localization.

The Help file system

The volume of text to be translated to localize the Help file is important. It is probably a major part of full product localization.

However, a large part of the work may already be available from Visual dBASE 5.x.

Investment in this item affects product acceptability on the local market.

The availability of localized online Help can also be a good reason to back a decision not to proceed with manuals localization.

The online manuals

While often having a large part of common material shared with the online help, this item is also closely related to the next one : online manuals localization should probably be considered in relation with the printed manuals.

This is one element which could be questioned if revenues do not permit full localization of the product.

The printed manuals

The additional cost for printing the manuals is of course more important than simple CD-ROM or diskette duplication.

However, other important costs have to be considered : cost of printing large minimum quantities in advance, warehousing, additional shipment costs, etc.

To reduce costs, only one printed manual could be localized.

Another alternate possibility would be to provide a third-party book translated into the local language.

The example files

Sample applications and other examples are an important element for the developer to learn about the functionalities and usage of a new development tool.

As an alternative to a costly full localization, one significant example only could be fully localized.

Such sample application could cover the subject of creating internationally enabled applications, for instance, and include examples of localized resources in EU locales.

Additional files

Some additional files may also need localization. The FNF files for the Expression Builder come to mind.

Markers for a winning strategy

Clearly speaking, what are the choices ?

1. Selling the US version as is

When applied in markets where a localized version was previously available, this is equivalent to abandoning selling the product altogether.

Further, not only will the market be lost for this product, but it is also doubtful users will migrate to other products proposed by the vendor who they may feel has abandoned them.

2. Minimal "user-oriented" localization

This solution would include localizing :
  1. The BDE.
  2. The runtime virtual machine.
  3. The deployment utility.
This would make it possible to deploy localized executables.

The solution could perhaps be of use to developers of internationally enabled applications and to some multinational companies. They could then supply adequate executables of their applications to subsidiaries in French speaking countries.

This solution would not be suitable for the vast majority of French speaking developers.

3. Minimal developer-oriented localization

In addition to the items included in the former case :
  1. The Visual dBASE IDE.
  2. Minimal localized samples, as described.
  3. A manual or book.
This is the minimalistic requested solution for a product to be marketed to developers in French speaking markets.

4. Comfort developer option

In addtion to the former case, provide a localized Help system.

Of course, doing so this would provide added value to the development package tool in French speaking markets.

The right product to meet customer expectations

Clearly speaking, Visual dBASE 7 should comply with level #4 for localized features in order to gain satisfactory market acceptance in most EU countries.

Level #3 can be considered as a minimal backup solution where adequate investments for level #4 cannot be met.

Level #2 would only meet the demand of English speaking developers who want to build localized applications for users in EU countries.

Level #1 will result in drop of sales to null in several EU countries, in addition to loss of Borland image for current dBASE users. This would most certainly be the case in French speaking markets, for instance.

The EU box and gradual localization package project as presented in this paper provide the framework for an adequate response to the challenge at hand. Instead of relying on conservative moves, I have no doubt Borland will choose an innovatory solution to build for its future in the European Union unified market.

François Ghoche
August 1997