Easyling Release Notes - 2015 February
Mar 13, 2015 - Easyling.com
With the second month of the year passed, we can already tell we’re looking at a busy year: we have two new teammates, and a few little goodies to ease your translation work. Now you can mark XMLs as translatable even after having been added to the resources, add custom request headers to the crawler’s requests, see the date an entry was added to the project, pre-translate multiple languages in one go, we have a new JSON path tester/analyzer, and the ability to highlight search terms in the Workbench. See the details after the break!
In light of last month’s massive expansion of the Advanced Settings area, and the inclusion of XML translation, we also added the ability to select these files from the Resources view, and mark them as translatable after the relevant XPaths were specified. You simply need to switch the Resources view to it List mode, hover your mouse over the XML, and click the Translate button to move it into the Pages view for translation. Of course, you’ll still have to extract the content from it before you can translate it.
Some servers we’ve seen require special headers to be inserted into requests to serve their pages, for example, an Accept-Language header. Normally, our crawler is intended to be as generic as possible, so it will not include any special headers in its requests, but if you enter them into the text field in the Advanced Settings menu, you can include such headers. This is generally only needed if the crawl fails, and the only difference you can find between a working and a non-working request is a difference in headers, but it may just be the thing you need to be able to conduct a word count.
[caption id="" align=“alignnone” width=“900”]
Translating a continuously updating site is difficult, to say the least. Convincing your client that you, in fact, finished the job you were contracted to do is even harder. We’ve implemented multiple features to make this easier in the past: Work Packages (named exports that capture the state of the project at the time they’re created and contain XLIFFs split up by word count to even out the load across translators), Page List-/Translation Memory freezing (preventing the addition of new pages or entries after a crawl is complete to keep the site in the state you were contracted to translate), and Source caching (storing a snapshot of the remote server responses, then re-using them, in order to mask any changes in the source itself). But there are times where even this not enough. For those times, we implemented displaying the date an entry was picked up in the Workbench: with the History tab open, selecting any entry will display a new History entry as the first, the date that entry was added to our database, serving as absolute proof of the given entry being in the scope of your contract (or not…).
[caption id="" align=“alignnone” width=“900”]
For projects with many target languages, conducting machine translation or applying TMs can be a tedious task, going into the Workbench, conducting the process, and switching languages (unless Auto-pretranslation is enabled). If the project has many pages with lots of entries, it can even drag on for a while before you can switch languages. At least, that used to be the case. Now, you can start a pre-translation for one or more (or all) target languages straight from the Dashboard. Furthermore, it will run as a background task, leaving you free to move to your other projects to repeat the process, start a new project altogether, do the paperwork (or just grab a coffee).
[caption id="" align=“alignnone” width=“900”]
Javascript: it makes websites pretty, web designers happy, and localization specialists furious - its ability to alter the page after download, including inserting new content, can be an endless source of headaches as they try to hunt down just where that untranslated bit of text is coming from. Although we’ve had the ability to translate Javascript/JSON for some time, up to now, actually setting it up required someone well-versed in the language to identify the paths to the content. Usually this meant enlisting our help, hiring a contractor, or spending your valuable time poring over the source code as you tried to decipher just what the designers did. And then enter the Javascript Analyzer: once you open it up with the link under the Search Paths field, you either feed it the script by pasting it, or point at the URL on the project so it can fetch the script itself, you press the Analyze button, and behold! everything we can find is highlighted in red (with a convenient button next to them to add the paths to the included ones), and everything we already extract is highlighted in green. Now it’s just a matter of scrolling through the analyzed script, adding everything that looks important to you, and copying that set into the search paths field once you’re done. Just don’t forget to mark the scripts as translatable in the Resources view, and crawl them to extract the entries once you’re done with the search paths!
[caption id="" align=“alignnone” width=“900”]
The last enhancement is something that may seem trivial, but can be very pleasing in large projects: when searching, the Workbench now highlights the search term in the result set in yellow. This is most useful when you enter a regular expression, whose matches can take very different forms (but fitting one common pattern), which are particularly hard to look for.
And finally, two enhancements to our team as well: starting February, we expanded our team with a new Support Engineer and a new frontend developer. This way, we can crank out the new features even faster, and we can provide even better support to our valued customers. Don’t be shy about directing your questions to us, that’s how our product evolves and becomes better suited to serve your needs!