History: Alain's comments on translation tracking architecture, 2008-02-05
Preview of version: 6
- «
- »
These are Alain's comments on an architecture document written by LPH. The document describes how the system will track the relationships between changes made and translated in different language versions of a same page.
The architecture is attached at the bottom of this page.
I like the fact that the framework is highly flexible. In particular, it is completely agnostic about whether or not we have a master language or pivot language or none. This will give us flexibility to experiment with different types of workflows.
I also like the way you address the need for preserving the complete translation relationship record, while allowing fast display (using translation bit flags).
On page 2, the document says:
The question I have is what does "exposed" mean in this context? It seems to me that you are assuming that as soon as the user enters a transaction to transate a change from say, En to Fr, and he clicks on save, then the Fr page is deemd to have been exposed to the En change.
But that assumes that translators will always translate a whole change in one go and will not want to do an interim save. This may not be the case when translating long changes.
I wrote a bit about this on this page Alain's test and feedback, 2008-02-05... look at Issue #9.
Often there are some things that are too cultural and are not appropriate in other languages. In cases like this, translators must have the option so simply not integrate a particular change in their language version.
I don't think there are limitations in the architecture w.r.t. that, but just wanted to raise the issue.
Eventhough I am a mathematician by training, I find I have no more stamina for forumalaes anymore ;-).
BTW: What you show at the bottom of page 2 are formulaes, not equations.
I had trouble understanding them. In particular, you say that alpha is the source page, and omega is the set of translatios for a given page. Given that, how can you say that alpha is an element of omega when the elements of omega are not pages? Also, you didn't define what Phi was.
I can see how the translation bit flag hack will allow you to quickly determine if a page in one language needs to be exposed to changes from another language.
It's not clear to me though how you will determine WHICH changes, i.e. which part of the source page need to be brought into the target page.
Will there be some sort of version number associated with a particular bit in the bit mask?
It seems to me that every time the user saves a page (while authoring original content), he generates a new translation bit. Does this mean that when the time comes to propagate the changes to other languages, the translator will need to do a translation transaction for each of those consecutive bits? Or will "consecutive" translation bits (exact meaning of "consecutive" to be determined) be somehow aggregated into a single translation bit?
I wrote a bit about this on this page Alain's test and feedback, 2008-02-05, under Comment #7.
The architecture is attached at the bottom of this page.
Very flexible framework
I like the fact that the framework is highly flexible. In particular, it is completely agnostic about whether or not we have a master language or pivot language or none. This will give us flexibility to experiment with different types of workflows.
I also like the way you address the need for preserving the complete translation relationship record, while allowing fast display (using translation bit flags).
User still needs to manually label synchronisation points
On page 2, the document says:
Trying to identify the point in time when two pages are synchronized would usually require human validation. Instead, this model keeps track of which unique modi cations the page has been exposed to. Pages that have been exposed to the same content are considered equivalent. Similarly, pages that have been exposed to more content can be considered superior.
The question I have is what does "exposed" mean in this context? It seems to me that you are assuming that as soon as the user enters a transaction to transate a change from say, En to Fr, and he clicks on save, then the Fr page is deemd to have been exposed to the En change.
But that assumes that translators will always translate a whole change in one go and will not want to do an interim save. This may not be the case when translating long changes.
I wrote a bit about this on this page Alain's test and feedback, 2008-02-05... look at Issue #9.
Can translates decide to not incorporate a particular change from a language
Often there are some things that are too cultural and are not appropriate in other languages. In cases like this, translators must have the option so simply not integrate a particular change in their language version.
I don't think there are limitations in the architecture w.r.t. that, but just wanted to raise the issue.
Formulaes are not clear
Eventhough I am a mathematician by training, I find I have no more stamina for forumalaes anymore ;-).
BTW: What you show at the bottom of page 2 are formulaes, not equations.
I had trouble understanding them. In particular, you say that alpha is the source page, and omega is the set of translatios for a given page. Given that, how can you say that alpha is an element of omega when the elements of omega are not pages? Also, you didn't define what Phi was.
Associating translation bits with parts of pages
I can see how the translation bit flag hack will allow you to quickly determine if a page in one language needs to be exposed to changes from another language.
It's not clear to me though how you will determine WHICH changes, i.e. which part of the source page need to be brought into the target page.
Will there be some sort of version number associated with a particular bit in the bit mask?
Will consecutive translation bits be merged together?
It seems to me that every time the user saves a page (while authoring original content), he generates a new translation bit. Does this mean that when the time comes to propagate the changes to other languages, the translator will need to do a translation transaction for each of those consecutive bits? Or will "consecutive" translation bits (exact meaning of "consecutive" to be determined) be somehow aggregated into a single translation bit?
I wrote a bit about this on this page Alain's test and feedback, 2008-02-05, under Comment #7.
History
SideMenu
Latest Changes
No records to display ...more
Search
Log In
Upcoming Events
No records to display