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)
Solution #2 Write all translations before deploying Pros: – Development can be parallelized – Translations are more concrete Cons: – Still damn slow to deploy
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
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
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
namespace Symfony\Component\Translation\Loader; use Symfony\Component\Translation\MessageCatalogue; use Symfony\Component\Translation\Exception\InvalidResourceException; use Symfony\Component\Translation\Exception\NotFoundResourceException; /** * LoaderInterface is the interface implemented by all translation loaders. */ interface LoaderInterface { /** * Loads a locale. * * @param mixed $resource A resource * @param string $locale A locale * @param string $domain The domain * * @return MessageCatalogue A MessageCatalogue instance */ public function load($resource, $locale, $domain = 'messages'); }
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
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
But wait… is a bundle the good solution? – What about maintaining several applications? – Better to have a centralized platform to perform all the translations
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
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.
And more to come… • Proofread mode for editor • History • Statistics • Screenshots • Glossary • Tags • Support more formats (Android, iOS, Rails…) • etc.
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.
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
mattketmo
chatwork_hr
maimux2x
tapompom
shibe23
junk0612
murabayashi
ogiwarat
kdai
ivargrimstad
daisukeshinoku
amixedcolor
shimabox
jponch
philhawksworth
jnunemaker
eileencodes
nonsquared
holman
malarkey
kevinliebholz
philnash
schacon
deanohume
dotmariusz