Lokalise
•Download as PPTX, PDF•
2 likes•417 views
The light talk given at Droidcon DE 2017
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Lokalise
Similar to Lokalise (20)
More from Eugen Martynov
Recently uploaded
Recently uploaded (20)
Lokalise
- 1. Localise? Lokalise! The current way how we do it
- 3. @jack_martynov https://github.com/emartynov Android engineer at Yolt Eugen Martynov
- 4. BEFORE
- 5. • Initiated by developer • Professional translator • Checked by developer Flow Before
- 6. • Wiki, XSLT, jenkins, git commit • Excel/Ruby, git submodule • OneSky/Transifex, command line, automated/manual commit Tooling Before
- 7. • Git sub module sync nightmare • Excel file merge conflicts • Unsync between platforms • Unused texts • Editing the wiki Issues Before
- 8. NOW
- 9. Page title
- 10. • Material design recommendations about writings • Naming - common__oh_dear and add_bank__incorrect_credentials_error_title • Communication • Keys tagging - all and by new feature Agreements Now
- 11. • Lokalise • SwiftGen • cli • slack Tools Now
- 12. Lokalise - One project for all platforms • Different keys per platform • Specific keys for one platform • Custom attributes - c-data and translatable
- 13. Lokalise - Import/Export • Auto detection of uploaded language • A lot of supported formats • Settings for order keys when exporting • Replace line breaks with n • Export all, translated, proofread, etc • Export by tags
- 14. Lokalise - Unified placeholders
- 15. Lokalise - Plurals support
- 16. Lokalise - Screenshots • PNG, JPG and GIF • String matching from screenshots
- 17. Lokalise - Activity log
- 18. Lokalise - Yolt localisation flow support • One project for both platforms • Tagging for built and new features • Proof reading • Slack integration with CLI and API • Supper fast and responsive support (even for free version). They really rock!
- 19. • IMO not clear payment tiers and limitation by number of sitting places • Import doesn’t recognise placeholders • Cumbersome recovering from mistakes with snapshots • “As is” search of duplicates • Proof read is not recorded in activity log • CLI is binary and result is zip archive instead of string files Lokalise issues Now
- 20. FUTURE
- 21. • Not natural unused strings exclusion • Updating strings, especially changing keys • Not fully automated Flow issues Future
- 22. REFERENCES
- 23. • Transifex: https://www.transifex.com/ • OneSky: https://www.oneskyapp.com/ • Lokalise: https://lokalise.co • SwiftGen: https://github.com/SwiftGen/SwiftGen • Material Design: https://material.io/guidelines/style/writing.html • Square shuttle: https://github.com/square/shuttle Mentioned tools References
Editor's Notes
- Hello everyone and thank you for coming. Today I will talk about “Our” way, and I hope you will find it interesting. The misspelling in the title is not mistaken. Before we start - how many of you are already using the tool Lokalise? All of you might start thinking about another topic since you know quite a lot from my presentation.
- I have the list of things that should be part of my new greenfield project - automation, continuous integration, continuous delivery, architecture documentation and agreements, etc. And having localisation is one of them. During this presentation I will touch different approaches for localisation in the mobile projects, pros and cons, fails and possible improvements. So answers to these questions: 1. What - Proper localisation 2. When - As soon as possible, from start 3. Why - It is pleasant and saves you a lot of effort in the future 4. How - The rest of content of this presentation
- Usual glory slide about me. My name is Eugen, and I’m from the country with windmills and where people drink water from a tap. You can reach me on twitter or developer social network. I worked on the great projects with small and big companies like eBuddy, Minddistrict, Phillips and Yolt. I currently work at Yolt, the fin tech that tries to help people manage their money better. If you’re from the UK I encourage you to give a try to our application. The content of the presentations is based wholly on my experience.
- So how was it for me involved projects before.
- The flow was initiated by a developer when he was starting the story. He would add strings to localisation sources. After, professional translators would give proper translations. And finally, they will end up in the product at some time before release.
- For the eBuddy strings were first at the wiki and then wiki change would be noticed by TeamCity, and it would run XLST transformation to the current project and commit it to the develop branch. At that time it was still svn. Later all localisations migrated to OneSky and its management was the responsibility of PO/QA. However, a developer should export and commit it to feature branch (it was already git). For the Minddistrict the flow was similar however tool name was Transifex. I worked later on Philips uGrow and for reasons they used Excel, localisation source was in git submodule and managing it was developer responsibility. However, before release, professional service would be involved, and final copies would be committed into the projects. As for Yolt, we didn’t have the source of localisations, copy check was part of DoD, but syncing values and tracking changes was all developers responsibility.
- Nevertheless to say that git submodule and Excel were the hardest way because of tools nature. The first Yolt approach was also the kinda nightmare for synchronisation and proof reading.
- So lets talk about nowadays.
- We took time to discuss and agree on the localisation process. Notice that having the copy check is still part of our DoD. The story is not ready if it doesn’t have yet approved texts.
- Our verbal and written agreements. 1. We should use Google guideline mostly about Capitalisation and Punctuation. 2. We divide localisation key to universal and particular feature usage. The first one has to have `common__` prefix and second - the `<feature>__`. Common keys suffix is whole or majority of text `common__ok` or `common__it_is_greate_weather_today`. Feature specific keys should be descriptive to be easily located like `add_bank__incorrect_credentials_error_title`. 3. All required localisation interactions are happening in the slack channel - requests for proof read, discussions of the details and challenging translator.
- So we use Lokalise as the main source of truth for our localisations. Major of actions are automated. We have two slack channels - human one to discuss all changes and questions, as well tools one that states all actions from Lokalise.
- So let's zoom in Lokalise. The key difference for us is one project that holds localisations for all platforms. None of above commercial tools has it. There are blog posts about managing cross platform projects, but IMO they don’t make life easy. All of them support copying localisation between projects, but they still are different projects. As you can see from the screenshot, you can have multiple keys per platform as well it is easy to have keys specific only for one platform.
- You can manually export/import localisation as well there are API and CLI tools to automate it. Small details - Lokalise can guess language form file, but I would advise you to select it manually. As for us, it detected that we use American English instead of British because we had a small mix. Which was not spot at the first run and tool gave us warnings about British phrases present. It can convert new lines to /n symbols.
- Because of the support for multiple platforms, it must deal with placeholders in strings. And it does it perfectly.
- As well it is modern tool and plurals is seamless in.
- I cannot also imagine better context than a screenshot. However often it is not enough and requires adding descriptions and explanations. You could also import multiple screenshots, and Lokalise has magical checkbox “Recognise texts”. However, it is simple - it doesn’t recognise nearby texts like dialogue title and dialogue message. And it deals with it funnily. I don’t know exact algorithm, but it decides if the text is on the picture by several first words of the phrase. So I advise you to check correctness screenshots assignments after the import.
- Small feature but quite useful is activity log where you can see actions that were done under the project by team members.
- And finally supports our flow fully: 1. One project for all platforms 2. Tagging for built and new features 3. Proof reading 4. Slack integration and CLI So we are almost happy with our flow and tooling. Lokalise matches us in our needs. As well they have super responsive support from developers.
- Read the slide
- So what about Future. I’m was saying “almost happy”, “quite satisfied”. So let's talk about current unresolved issues.
- There are still issues present - in attempt to not include unused strings we are using tags, and it requires manual selections during exporting and manual changes after the feature is done. Slack is a great tool, but it is quite hard to find reasons for some decisions. As well it is often pain when the released key is changed for good purposes. As I said keys are not automatically added, the proof read is requested in slack manually, some ritual with tagging is required to avoid good strings.
- I named several services and here are references to them. I also added the link to material guidelines about writing.
- Thank you for your time. Do you have any questions?