Code Gear

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 – [email protected]

• 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

Localization

The Delphi approach • Resource management – Isolated resources – System locale code / suffix • Resource precedence 1. CodeGear registry value override 2. Local system locale 3. Executable / DLL resources • Delphi ITE – resourcestring – Form definitions • External Translation Manager – Distributed translation – Does not require complete Delphi IDE

Localization

The 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

Localization

The 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 study

Environment and Prereqs •About 10 markets – Europe, USA, Asia / Australasia •3 application areas – Factory – Retailer – End user ~5 installations ~350 installations ~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 paradise

Development 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 Registry file to copy and register dll’s to register Delphi components •Component update distribution – New versions of components updated from VSS – Re-register using files above

Today – The structured paradise

Build 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

Today – The structured paradise

Localization •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

Language management

Language Management

Central 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 Management

Build flow Delphi Build .drc

.exe / .dll

.DEU

.FRA

.ESP

.ENG

.bpg

LangMan DB DEU FRA ESP ENG Translation

Language Management

Build flow LangMan DB .exe / .dll

.DEU

.FRA

.ESP

.ENG

Installation package

Language Management

The 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

FinalBuilder

Preparing for build •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

FinalBuilder

Build 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

FinalBuilder

Build 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

FinalBuilder

Deployment generation •Update databases – Each database is attached – General and market specific scripts executed on database – Database detached •Execute Wise installation generator – Wise compiles installation executable

FinalBuilder

Deployment distribution •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

FinalBuilder

Future enhancements •Update CM system – Update status of cases included in current build – Set ”Available from build” on new completed cases included in build