agility in your
translation
workflow
@MattKetmo
#PHPTour Lyon 2014
Slide 2
Slide 2 text
Who am I?
Matthieu Moquet
@MattKetmo
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
Agility
Slide 5
Slide 5 text
“Agile software development
is a group of methods based on
iterative and incremental
development.”
Slide 6
Slide 6 text
In other words,
DEPLOY OFTEN
Slide 7
Slide 7 text
What’s your
development workflow?
Slide 8
Slide 8 text
2 weeks SCRUM
8 days development
2 days
bug fixes
freeze features
deploy
Slide 9
Slide 9 text
SIMPLE
WORKFLOW
o 1 week planning
o Merge once it’s ready
o Several deployments /day
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
Who makes the translations?
When do you translate?
How do you proceed?
What about translations?
Slide 12
Slide 12 text
Solution #1
Write all translations before starting
developments
Pros:
– Better understanding of the final rendering
Cons:
– Can’t update specs later
– Damn slow (not very agile)
Slide 13
Slide 13 text
Solution #2
Write all translations before deploying
Pros:
– Development can be parallelized
– Translations are more concrete
Cons:
– Still damn slow to deploy
Slide 14
Slide 14 text
Solution #3
Don’t care about untranslated phrases in
production…
…since it’s not developers’ problem
Pros:
– Developers are more independent
Cons:
– Phrases can be untranslated for undefined time
– Can’t translate before next release
Slide 15
Slide 15 text
Solution #4
Decouple your translation process from the
development workflow
Pros:
– Developers are totally independent
– Easy to update any content strings
Cons:
– Need tools to follow the translation flow
Slide 16
Slide 16 text
Our solution
Slide 17
Slide 17 text
Developers create the default translations
– in English (sometimes in French)
– taken from specifications… or their mind
Slide 18
Slide 18 text
Translators do the rest
– when a feature is developed (before production,
once it’s on staging)
– after deploying (to update default translations)
– long after, because of a product change
Slide 19
Slide 19 text
deploy your code
then
update your translations
Think your translations as an independent
asset from your code base
…like a CMS
Slide 20
Slide 20 text
YOU WILL NEED A DATABASE
Slide 21
Slide 21 text
o Create & Update translations with built-in app
o No translations stored in code source
o Import from DEV env to PROD when deploying
Slide 22
Slide 22 text
We then built a similar module with
our brand new Symfony website…
BlablacarTranslationBundle
Slide 23
Slide 23 text
o English translations in Yaml files
o Pushed to database when staging
o Translators only work on production dataset
Slide 24
Slide 24 text
Slide 25
Slide 25 text
Translations Deployment (lazy mode)
o Avoid querying the database for each HTTP request
o Only store the last modification time on a Redis key
o Deploying translations means updating the Redis token
HTTP
Request
Translator
isFresh()
SELECT
translations
fwrite
app/cache
Slide 26
Slide 26 text
Debug Mode
Slide 27
Slide 27 text
Will you open source your
TranslationBundle?
Slide 28
Slide 28 text
Nope!
Our editing tool is too much coupled
with other layouts & services.
Slide 29
Slide 29 text
and there are already some
Symfony bundles doing the job
o Kunstmaan/KunstmaanTranslatorBundle
o lexik/LexikTranslationBundle
o servergrove/TranslationEditorBundle
o schmittjoh/JMSTranslationBundle
o Elao/ElaoFormTranslationBundle
o Incenteev/IncenteevTranslationCheckerBundle
o matteosister/TranslationBundle
o Wiakowe/TranslationBundle
o Pierstoval/TranslationBundle
o fre5h/TranslationBundle
o GiZystems/TranslationBundle
o dinecat/I18nBundle
o PUGX/PUGXI18nBundle
o emmanuelballery/EBTranslationBundle
Slide 30
Slide 30 text
But wait…
is a bundle the good solution?
– What about maintaining several applications?
– Better to have a centralized platform to perform all
the translations
Slide 31
Slide 31 text
What about existing tools?
Tools to help translating an application
There are several! Mostly SaaS.
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
(free for open source softwares)
Slide 34
Slide 34 text
Clients
Slide 35
Slide 35 text
♥ UI
Slide 36
Slide 36 text
o Review / approval
o History
o Glossary
o Translation Memory
o Projects management
o Team organization
o Comments
o Statistics
Slide 37
Slide 37 text
API + CLI tool
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
(free for open source softwares)
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
github.com/akeneo/php-crowdin-api
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
o Crowdsourcing
o Translation Agency
o Translation Memory
o Glossary
o Machine Translation
o In-context edition
o Screenshots
o Statistics
o Review/voting system
o Webhooks
Slide 44
Slide 44 text
There are many more SaaS tools…
but, is it worth it?
Lots of tools,
but can’t find a satisfying one
Non-adapted to our current workflow
§ Unable to edit source
§ Unable to view/search by translation keys
§ No SSO compliant
§ etc.
Slide 60
Slide 60 text
We could adapt ourselves to
existing features
Slide 61
Slide 61 text
OR…
Slide 62
Slide 62 text
We could
roll our own
application!
Slide 63
Slide 63 text
must be fully
open source
Pleasant to code / play with
Doesn’t depend on a tier
Roll your own auth mechanism
Slide 64
Slide 64 text
should include the
basic features
of traditional tools
Review, glossary, history, etc.
And maybe more!
Slide 65
Slide 65 text
should be
flexible
Language/framework independent
Hackable
Slide 66
Slide 66 text
damn simple to use
Easy to install / configure
Simple workflow
Minimal interface
UX friendly
Slide 67
Slide 67 text
OpenLocalization
Slide 68
Slide 68 text
openl10n.io
v0.1
Slide 69
Slide 69 text
Started as a traditional
Symfony application
Twig
(a bit of) BackboneJS
FosRest
Slide 70
Slide 70 text
but that was not enough satisfying…
Slide 71
Slide 71 text
…and I wanted to play more with
Javascript
Slide 72
Slide 72 text
API first
No more session, Twig, etc.
Full Javascript client
Backbone + Marionette + RequireJS
Slide 73
Slide 73 text
Shipped with a CLI tool
à API client build with Guzzle 4
Webhooks / Web
Eager
Deploy translation files on each frontend servers
Lazy
Update a token and let servers update themselves
Slide 84
Slide 84 text
Webhooks / Mobile
Webhook will upload
translations on a CDN
On start-up, mobile app
download latest version
of translations
Slide 85
Slide 85 text
Webhooks / Others
o Make a PR on GitHub
o Push new commit
o Create backup archives
o …
Slide 86
Slide 86 text
And more to come…
• Proofread mode for editor
• History
• Statistics
• Screenshots
• Glossary
• Tags
• Support more formats (Android, iOS, Rails…)
• etc.
Slide 87
Slide 87 text
Interested in the project?
Feel free to contribute
Slide 88
Slide 88 text
or just have a look at the sources
if you’re just curious
github.com/openl10n
§ openl10n: The core project (API + javascript client)
§ openl10n-sdk: API client (Guzzle 4)
§ openl10n-cli: CLI tool
§ openl10n.js: In-context translations (not planned yet)
§ demo-(silex|symfony|angular|rails): Example
of application with a openl10n configuration
§ etc.
Slide 89
Slide 89 text
Back-end / Symfony
Domain/
– Split by main components (project, resources,
translations, etc.)
– Unit tests via PHPSpec
Bundle/
– Set the infrastructure
– Implements API & User management
– Functionnal tests via PHPUnit
Slide 90
Slide 90 text
Front-end / BackboneJS
o MarionetteJS + RequireJS (soon Browserify?)
o Bundles-like folders
o No tests L
o Is there a JS expert in the room?
Slide 91
Slide 91 text
Thank you
Slides available at
moquet.net/talks/phptour-2014-i18n
More information at openl10n.io
Leave feedbacks @MattKetmo