Problem/Motivation
We have amazing tools already and still the translator has NO idea about how it will look once the translation is published..
Job items have a reference url and thus the translator might get it and can see how it looked before.
However the translated content can not be previewed.
As of translator feedback, the lack of preview leads to most complains with jobs: difference in length for certain languages lead to broken design.
Proposed resolution
-implement route to preview translation content using entity view builder.
-give reviewers access to preview, display link on the review form if preview is supported.
-include hash key in url to provide external access check.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | Screen Shot 2016-02-12 at 9.06.49 AM.png | 441.95 KB | CTaPByK |
| #17 | preview_for_translator-1998060-17.patch | 7.28 KB | CTaPByK |
| #17 | interdiff-1998060-14-17.txt | 7.25 KB | CTaPByK |
| #13 | preview_for_translator-1998060-13.patch | 5.92 KB | CTaPByK |
| #14 | Screen Shot 2016-02-10 at 12.42.51 PM.png | 293.32 KB | CTaPByK |
Comments
Comment #1
Wartus commentedYes, i have the same request from our translator.
the first question he asked after i explained the setup was: "where can i preview my work before submitting?"
Comment #2
miro_dietikerWe have drafted this feature and while it would be (truly) amazing, we expect even the most basic functionality is more than a week of work. Also there would still be limitations and followups that needs to be fixed later.
So while it is broadly requested, no one funded it (and thus no one works on it as far as i know).
We also have different things of higher priority (smaller pieces, more quick progress).
Comment #3
miro_dietikerWith 8.x this is way better achievable... :-)
Comment #4
miro_dietikerWe have some kind of preview through the WYSIWYG support.
#2042727: Support for CKEditor instead of normal textarea field
This is not enough though. A common question is to proof if the text is properly wrapped in the original output. Sometimes translations just don't fit into the space intended.
Each source could offer a method to tell us if it supports inline preview.
If a source item supports inline preview, we can display a button for preview.
The button would open a separate tab or overlay and display the text entered in context of the source.
For entities, we can create a temporary item and render it.
Comment #5
miro_dietikerThis has been discussed with a translation services provider. Would be nice if we can work on this kind of page preview.
We even discussed to expose preview through the translator plugin so the translators on the online platform can trigger preview rendering. :-)
Comment #6
miro_dietikerI have been discussing this intensely with a customer that needs also preview rendering and offering the result to off site translators.
For this, we need to be able to persist preliminary translations that are not supposed to be accepted ever. Most importantly because we need to separately pull data and render the preview in a separate request...
The best fit for this would be to add a PRELIMINARY state that indicates a translation is there, we can preview it already, possibly even provide feedback, but we can not accept it yet due to remote workflow constraints. Most translators will not use this state at all.
There are also other approaches, but this seemed to be the best fit for TMGMT.
Any other opinions?
Comment #7
berdirSo, lets start with the basics, before we get to remote translator previews, which are about 5 steps away.
Note that not each step is a separate issue, but it makes sense to start small to get into the whole concept.
Step 0:
In the content source plugin/module, implement a route like /tmgmt/content/preview/{job_item}. For access control, use the accept job permission.
In there, load the entity from the job item, populate it with the target translation of the job item and view it using an entity view builder.
You can find most of this code in the content source plugin, which does all those things already (and then saves, instead of displaying). It's important that we do *not* save here. you can try to re-use existing code there but note that you must not change existing, public API's unless there really is no other way.
Step 1:
The next step is giving reviewers access to this preview. For that, implement a new interface, SourcePreviewInterface or so, that has a getPreviewUrl() method, which returns a a Url object if preview is supported. On the review form, check if the source implements this and if so, display it as a link.
Step 2: Access control. Similar to a CSRF hash, the built URl should include a hash, for example based on the job item data, like ?key=segk4gs3t3kdsfefr19.... Provide an access check that verifies that (by generating that key again from the job item data). That will allow external access .
Step 1 and two is probably a good first step for a first child issue. I'll add more explanations later. Of course, everything should be covered with tests.
Comment #8
CTaPByK commentedComment #9
CTaPByK commentedI start working on first step (step 0) to implement route for preview.
Comment #10
CTaPByK commentedWe make that step 0 for this preview, for now we have just implemented controller and route for preview.
After that we will continue with step 1 and create tests.
Comment #11
berdirUse injection to inject the dependencies you need.
Use $target_langcode instead, don't abbreviate variables (too much)
Do we really need this?
You should be able to just call $job_item->getData(). getting data is when you create a new job (item)
Comment #12
CTaPByK commentedHere is the new patch for step 0, i remove unnecessary methods and code.
Comment #13
CTaPByK commentedPatch with test coverage for preview.
Comment #14
CTaPByK commentedHere is patch with better test, also title for preview is modified.
Comment #15
thenchev commentedThe missing interdiff.
Comment #16
berdiryou should use $entity_type_manager and $this->entityTypeManager everywhere.
preview_type isn't really a singe, and below you then talk about preview mode?
I'd just call this what it is. $view_mode.
Also, I like adding it, but currently it's possible to actually use it.
What you should be able to do is add another argument to the route {view_mode}, and add the default value for it in defaults:
If that doesn't work, you can also define two routes, one with the view_mode argument, otherwise identical.
This only displays the node in the right language for me when accessing the site in that language. Since we are previewing a specific language, you should force that by passing $preview->language()->getId() as third argument.
We should use getTargetLanguage()->getName() instead. and call it $target_language then.
This is a lie, it doesn't return translation data. It builds the entity translation for the provided translation data. The @return is also completely wrong. Should be ContentEntityInterface instead.
Use $this->config()
you're not using the return value yet, so I don't think this is doing anything yet.
To test this, install tmgmt_demo and paragraphs demo. Make sure that the paragraph field is saved as a embeddable field in the settings. Then translate a node with paragraphs and view it.
This tests the wrong behavior. We want to see the *translated* title. Which, with the default test translator, is "de_$title".
I didn't say anything about admin :)
It's a preview if your content. You want to see that in the frontend theme. So just /tmgmt/content...
Comment #17
CTaPByK commentedIn this patch i try to fix all suggestions from latest review.
Comment #18
CTaPByK commentedHere is screenshot of testing preview with paragraph.
Comment #20
berdirRemoved the options from the route, Drupal can figure that out automatically. Tests still pass.
Committed.
Comment #21
berdirComment #22
thenchev commentedThere is an edge case when the preview is not working. When you start creating a job (didn't save it yet or submit to translator) we get an exception when you try to go to the preview for some job item. The target language in that stage is still undefined is the reason. I can make a simple check if is still undefined in the controller preview and redirect to the job with some message that the user needs to save the job first or submit to translator to view it. Not sure how important it is...
Comment #23
berdirGood catch. Lets handle that as part of the custom access check, just deny access if the item has no job (could happen if it's still in cart, that would be a fatal right now too) or the job is not active.