Details
-
New Feature
-
Resolution: Fixed
-
None
-
High
-
-
Description
Add Capabilities, to import an XML to generate the bilingual files and the review-files in conjunction with a XSLT stylesheet from it
Steps:
1) Switch from the current non-namespaced segmentation tags like span/div and non-namespaced classes like "selected" to T5 namespacing, e.g <t5segment class="t5selected t5alias" data-t5pageNr="2">Lorem Ipsum</t5segment>
2) Implement Export of a regularily imported XML to generate the VisualReview-Source for it if a XSLT is set in it and can be found as file.
a) wird ein Export angestoßen
b) Im Exportvorgang werden die Source Inhalte in die ja noch leeren Targets kopiert und mit den in 6) spezifizierten Segment Markern (t5:segment + segment nr in task) versehen.
i. Die Segmentmarker werden für xml/xslt direkt als HTML mit ins Segment geschossen. Da Okapi aber nur xliff-Tags in der Rückkonvertierung erwartet, sollte hier zunächst mit einer Transtilde gearbeitet werden, in die die IDs codiert sind. Nach der Okapi-Rückkonvertierung und der Erzeugung des HTMLs wird die transtilde dann in den korrekten HTML-Tag umgewandelt
ii. In einem späteren Entwicklungsschritt ist vorgesehen, statt der transtilde zunächst in unsichtbare Unicode-Zeichen codiert ins Segment zu schießen. Dann ist bei einer Konvertierung via LibreOffice, Indesign etc. keine Auswirkung aufs Layout vorhanden und die Zeichen können dann nachdem das HTML aus den PDFs erzeugt wurde wieder in die bereits t5-Tagstruktur umgewandelt werden
iii. Ebenfalls passt zu diesem Problem die Frage wie wir mit t5:segment Markern in nicht sichtbaren Bereichen z.B. alt Attributen umgehen. Auch das wird für das Worldtranslation xslt noch nicht umgesetzt sondern ist für später angedacht. Diese müssen für die Anzeige irgendwie umkonvertiert werden, sprich der Marker muss in das Elternelement gepackt werden. Eventuell das ganze in Schritt 12)
c) dies geht wie im bereits implementierten Okapi Export zu 9) Okapi und wir bekommen dann die originale, nicht übersetzte Quelldatei mit injecteten Segment Markern zurück.
d) Wenn es sich um eine XML + XSLT gehandelt hat, so muss via File Filters nach dem Okapi Export die XML + XSLT Konvertierung zu HTML angestoßen werden
e) Die so erzeugte/aufbereitete HTML Datei wird in den visualReview Ordner verschoben und der Visual Editing Import Prozess angestoßen
3) Add automatic generation of review HTML from XML/XSLT if XSLT is defined in the XML and exists as a file, add worker to decode the unicode-markers and replace with proper T5-HTML markers
EXTENSIONS:
4) Add management of multiple review files with mapping to the generated bilingual files (initially for HTML files based on XML-Import only)
- extent import as in 1) for multiple files
- if a task has multiple review-files, there is a foreign-key relation between LEK_files and LEK_visualreview_files to bind them. This constraint is optional, as the existing logic is a 1:1 relation of task and LEK_visualreview_files. A "order" field must be added to LEK_visualreview_files to define the order of files and to make a logical joint to the "segmentPage" column in LEK_visualreview_segmentmapping which expects following numbers like 0,1,2,3,4,...
- A UGLY disambuiguity is the now double-meaning of the column "segmentPage" in LEK_visualreview_segmentmapping, which may mean a section within a page (pdfToHtml output) or a real own refview-file otherwise
- Subdirectories for HTML-reviews inside of "visualReview" have to be generated. To keep compatibility with existing data, the first review-file (entry of LEK_visualreview_files) is stored in the directory directly, all others are stored in subfolders like htmlX, where the number X represents the "order" of LEK_visualreview_files
- A GUI has to be added to the Visual-Review Frontend to make switching between reviews possible
- A mechanism to reload the visuel review with a different file is neccessary when switching like above or selecting a segment located on a different page. Here is the problem, that the highlighting of the segment in the page to load has to be delayed
- Better would be a additional constraint between LEK_visualreview_segmentmapping and LEK_visualreview_files to be able to identify the needed review-file for a segment directly (and not implicitly via "order"). That would be an extra effort of 5-7h due to the needed changes in the frontend-logic. Also this would rise the problem of backward-compatibility, at least a script adding the needed constraints for existing data is needed then