Code Gear localization strategy CYBERCOM automated build process

1. CodeGear localization strategy CYBERCOM automated build process Custom developed localization for Delphi

2. 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

3. Jonas in brief • Jonas Rapp • jonas.rapp@cybercomgroup.com • 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

4. Localization The Delphi approach

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

6. 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

7. 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

8. Case study Software suite for an international customer developed by Cybercom since 2000

9. 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

10. History The wild wild west

11. 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

12. 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

13. 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...

14. Today The structured paradise

15. 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

16. 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

17. Today – The structured paradiseLocalization • 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

18. Today Language management

19. 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

20. Language ManagementBuild flow Delphi Build .drc LangMan DB Translation .exe / .dll .bpg DEU FRA ESP .DEU ENG .FRA .ESP .ENG

21. Language ManagementBuild flow LangMan DB .exe / .dll Installation package .DEU .FRA .ESP .ENG

22. 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

23. Professor Balthazar Today Automated build process with FinalBuilder

24. FinalBuilderPreparing 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

25. 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

26. 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

27. FinalBuilderDeployment 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

28. FinalBuilderDeployment 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

29. FinalBuilderFuture enhancements • Update CM system • Update status of cases included in current build • Set ”Available from build” on new completed cases included in build