CodeGear localization strategy
CYBERCOM automated build process
Custom developed localization for Delphi
Cybercom in brief• Cybercom is a high-tech consultancy
– that offers software development and IT-strategy services.
– our services mainly target the telecom, finance and industry sector and key customers in other sectors.
• Launched in 1995 and on the Nordic stock exchange’s since 1999.
• Offices in Denmark, India, Sweden, Singapore and the UK, and operations world-wide.
• Together we employ about 500 people.
• Our largest customer– Sony Ericsson, Ericsson, Nokia, Tele2,
Millicom, Teracom, ASSA ABLOY, Reuters, SEB, H&M, OMX
Jonas in brief• Jonas Rapp
• Consultant since 1996– System development, dba, architect
• Cybercom Group since 1998– Small independent companies, stock
market introduction, the Dark Ages, expansion
• Odd Delphi-developer– 1, 3, 5, 7, 2005, 2007
Localization
The Delphi approach
LocalizationThe Delphi approach
• Resource management– Isolated resources– System locale code / suffix
• Resource precedence1. CodeGear registry value override2. Local system locale3. Executable / DLL resources
• Delphi ITE– resourcestring– Form definitions
• External Translation Manager– Distributed translation– Does not require complete Delphi IDE
LocalizationThe Delphi approach – Pros and Cons
Pros
• Completely integrated with the development platform
• Transparent to developers and users
• ETM for distributed translation
• System locale override
• Support for repository
LocalizationThe Delphi approach – Pros and Cons
Cons
• ETM / ITE never passed the GUI guys...
• Shaky updating of form definitions
• Generally overkill
• Complex distribution of files to translators
• Master of data uncertainty
• No batch support
• No standard deployment method for ETM - manual copying of files
Case study
Software suite for an international customer developed by Cybercom since 2000
Case studyEnvironment and Prereqs
• About 10 markets– Europe, USA, Asia / Australasia
• 3 application areas– Factory ~5 installations– Retailer ~350 installations– End user~1000 installations
• 10-15 languages– Translated remotely by customer, compiled to resource libraries
• Common code– Some code is shared between the applications
• Business logic variations– Some custom functionality based on market
History
The wild wild west
History – The wild wild west...Build process
• Unsynchronized builds and releases– Supplier - Customer culture too loose, unspecified request and requirement
procedures– No release management– Separate modules built when needed– Separate modules delivered manually to market
• Uncontrolled build environment– No standard developer tools kit– Builds performed on any developer PC– Some modules only possible to build on specific PCs with correct tools and
components
History – The wild wild west...Language management
• Strings declared as resourcestring– Strings used in code extracted to resourcestrings for translation
• Form texts scanned by custom made tool– Generates .pas-file with texts in resourcestrings– Form file parsing developed and expanded ad hoc
• Languages generated with Delphi Translation Manager– Generates lots of overhead with duplicated form definitions for each
language
• Distributed asynchronous translation– .rc-files updated by Delphi languages build– Translations being performed on .rc-files with custom made tool– .rc-files sent back to developers to be used in next build
History – The wild wild west...Obvious problems
• Uncontrolled installation status– Customers may have any combination of versions in different modules
• Arbitrary binaries– Builds performed in ”dirty” environment on developer PC
• Translation Manager problems– Form definitions duplicated– Master of data problems– ReadOnly attribute cascaded
• Language resources do not match exe/dll– Distributed binaries with different structure than existing language
resources
• Messy handling of .rc-files– Merging translated files into new Delphi-generated files, while a third
version of the file is just distributed without latest translations...
Today
The structured paradise
Today – The structured paradiseDevelopment environment
• Click-once-setup of Delphi environment– All components and pre-reqs structured in VSS– Environment variable defines local project root
• Automatic registration of components– Command file to copy and register dll’s– Registry file to register Delphi components
• Component update distribution– New versions of components updated from VSS– Re-register using files above
Today – The structured paradiseBuild environment
• Dedicated build machine– Not infected by developer whims to ”try some new stuff”...– VPC with all prereqs installed
• Safe reproducable VPC environment– Not dependent on a specific PC, the VPC image can be used on any PC
(actually even on a contaminated developer PC...)
• Complete process controlled from check-out to published updates
– Manual interaction minimized as FinalBuilder controls all steps in the process
• Strings declared as resourcestring– Strings used in code extracted to
resourcestrings for translation
• Forms scanned by custom tool– Generates .pas-file with texts in
resourcestrings– Form definition parser same as Delphi
itself uses
• Translation projects generated by custom tool
– Complete Delphi projects with references to base project form definitions and including .rc-files and collecting project group are generated from language database
Today – The structured paradiseLocalization
Today
Language management
Language ManagementCentral database
• Language Management database– All translations stored in central database– Resource history maintained for non-
chronological builds
• New builds update database– The Delphi .drc-file is parsed to update the
database with information of resourcestrings in current version
• Web based UI– Translations are updated in the database.– Access control restricts who updates what
Language ManagementBuild flow
Delphi Build .drc LangMan DB
Translation
DEUFRA
ESPENG
.bpg.exe / .dll
.DEU.FRA
.ESP.ENG
Language ManagementBuild flow
LangMan DB
.exe / .dll
.DEU.FRA
.ESP.ENG
Installation package
Language ManagementThe future of Cybercom application localization
• Repository– Automatically translate single words– Translate all similar resourcestrings
• Integration with other development platforms– LangMan database may be updated from, and update to, other platforms e.g.
Visual Studio
• Local client– Publish webservices on LangMan server– Local clients consuming webservices for data retreival and update– Radical GUI advantages to web based GUI– Check in/out projects and languages etc
• Translating binary resources– Images, sounds etc
Today
Automated build process
with FinalBuilder
Professor Balthazar
• Set version number– Major, Minor and Release is set manually– Build number is controlled by the automated build process– Version number is set on all binaries compiled from FinalBuilder
• Send e-mail to project group– Alert team members that the build is started
• Label project tree in VSS– If this is a new build with latest available source, a label is set in VSS source
structure
• Get labeled tree from VSS– The version to build is fetched from VSS
FinalBuilderPreparing for build
FinalBuilderBuild and Localization actions
• Execute FormTextScanner tool– Form texts parsed to resourcestrings– Method to set form properties at runtime
• Build Delphi-project modules– exe/dll generated– drc file generated
• Execute Delphi drc -> LangMan updater– Updates LangMan database with resources from current version
FinalBuilderBuild and Localization actions
• Translate languages– Build process may be paused to allow translations of new and changed
resource strings
• Execute LangMan -> rc generator– rc-files for all included languages– Delphi projects for all languages– Delphi project group for language projects, used in a developer
environment
• Build Delphi language projects– Generate resource binaries
• Update databases– Each database is attached– General and market specific scripts executed on database– Database detached
• Execute Wise installation generator– Wise compiles installation executable
FinalBuilderDeployment generation
• Copy files to internal server– Installation files for test staff made available on in-house server
• FTP installation to web based distribution site– Installation files for customer tests transferred over FTP to public server– Files for Automatic update transferred to web server
• Translation files distributed– .rc files (where still used) transferred to web server for distributed translation
• Build output archived– All builds are archived on local servers
• Build logs published– Logs from all build activities are published as html document– Build history is published as html document
FinalBuilderDeployment distribution
• Update CM system– Update status of cases included in current build– Set ”Available from build” on new completed cases included in build
FinalBuilderFuture enhancements
