Change Details

As preparation for VE, and also as a consolidation of usecases that were patched up over last 2 years, we need to reorganize the classes in better way. It is better to do now before VE integration so that the tech debt does not carry forward. ----------- **Background**: 1. CX was developed iteratively for last 2+ years. During that time, features were added in several stage of product development. In the beginning of the project, there was a highlevel understanding of features but not the details. So the architecture was a flexible one where modules can be plugged and get this done. This worked very well for us and we were able to add features fast. But the approach caused code duplication, less organized hierarchy of similar usecases. So a consolidation and reorganization of these use cases is much needed. 2. The general direction in which CX is moving is to align with the MediaWiki extension good practices which includes OOJS UI based standardised frondend. Also CX need much improved editing experience with the help of VE. OOJS and obvioulsly VE follow object oriented architecture heavily. CX's plugin based and global hooks based architecture is ill suited to mix with them. So the above mentioned organization should follow OO architecture for the best match. 3. The patched up CX code showed some shortcomings recently and we can solve it during this reorganization. This excercise will be done in several iterations and the code in production wont switch to this new codebase till everything is in place. The new codebased will be available with cxx=1 param in URL. **Concepts** Following coding, architecture concepts are followed 1. Data manipulation, adaptation are done in DataModel classes and made independent of UI or contentedtiable elements. Changes in contenteditables are updated in datamodels whenever content changes. 2. Definition of translation unit - Any translatable element which has correspondence in target language, automatically adaptable or manually translatable and editable are defined as TranslationUnit. 3. Clean hierarchy of translation units 4. The translation context is available in Translation Units and other classes by dependency injection. Avoiding the mw.cx globals for context 5. A translation unit can have zero or more translation tools which are tools shown in translation column. 6. All translation units are wrapped in <section> tags 7. Methods to be designed to help unit testing as much as possible 8. OOJS UI widgets 9. Object oriented code arrangement with the help of OOJS **Checklist** [x] Migrate The 3 column based UI frame to OOJS [x] Rewrite the translation source selector using OOJS widgets [x] Define a data model hierarchy - abstract the translation units [x] Source page loading [x] Rendering translatable sections in source column [x] Categories widget migration (https://gerrit.wikimedia.org/r/#/c/333894/) [x] Placeholders for source sections [x] Section alignment on edits [x] Cache management for links, title pairs (New in this version. it did not exist properly in old code) [] Success, error message integration [x] Data model and UI separation [x] Registries for tools and translation units [] Automatic adaptation - [x] Link adaptation - [x] Reference adaptation - [] Image adaptation - [] Template adaptation - [] Gallery adaptation - [] Math extension adaptation - [] Poem adaptation - [x] Category adaptation [x] Tool card management system [] Tool cards - [] Link tool : A dummy tool exist, displays adapted target title - [] Dictionary tool - A dummy card exist. - [] Search tool - Tool is present, search is not present - [] Formatting tool - [] Reference tool - Reference card shows adapted reference and a reference removal button(noop) - [] Template tool - [x] Instructions tool [] Template translation system [x] Progress bar widget using OOJS [] Progress calculation integration [] Abuse detection [] Restoring a translation [] Saving a translation [] Publishing translation - [] Building the target page document from data models - [] Conflict checks - [] Cleaning up for clean wikitext [] Translation linting [x] Separation of two codebases using URL switch [] unit tests - Some tests exist, code is written to help easy unit testing.

As preparation for VE, and also as a consolidation of usecases that were patched up over last 2 years, we need to reorganize the classes in better way. It is better to do now before VE integration so that the tech debt does not carry forward. ----------- **Background**: 1. CX was developed iteratively for last 2+ years. During that time, features were added in several stage of product development. In the beginning of the project, there was a highlevel understanding of features but not the details. So the architecture was a flexible one where modules can be plugged and get this done. This worked very well for us and we were able to add features fast. But the approach caused code duplication, less organized hierarchy of similar usecases. So a consolidation and reorganization of these use cases is much needed. 2. The general direction in which CX is moving is to align with the MediaWiki extension good practices which includes OOJS UI based standardised frondend. Also CX need much improved editing experience with the help of VE. OOJS and obvioulsly VE follow object oriented architecture heavily. CX's plugin based and global hooks based architecture is ill suited to mix with them. So the above mentioned organization should follow OO architecture for the best match. 3. The patched up CX code showed some shortcomings recently and we can solve it during this reorganization. This excercise will be done in several iterations and the code in production wont switch to this new codebase till everything is in place. The new codebased will be available with cxx=1 param in URL. **Concepts** Following coding, architecture concepts are followed 1. Data manipulation, adaptation are done in DataModel classes and made independent of UI or contentedtiable elements. Changes in contenteditables are updated in datamodels whenever content changes. 2. Definition of translation unit - Any translatable element which has correspondence in target language, automatically adaptable or manually translatable and editable are defined as TranslationUnit. 3. Clean hierarchy of translation units 4. The translation context is available in Translation Units and other classes by dependency injection. Avoiding the mw.cx globals for context 5. A translation unit can have zero or more translation tools which are tools shown in translation column. 6. All translation units are wrapped in <section> tags 7. Methods to be designed to help unit testing as much as possible 8. OOJS UI widgets 9. Object oriented code arrangement with the help of OOJS **Checklist** [x] Migrate The 3 column based UI frame to OOJS [x] Rewrite the translation source selector using OOJS widgets [x] Define a data model hierarchy - abstract the translation units [x] Source page loading [x] Rendering translatable sections in source column [x] Categories widget migration (https://gerrit.wikimedia.org/r/#/c/333894/) [x] Placeholders for source sections [x] Section alignment on edits [x] Cache management for links, title pairs (New in this version. it did not exist properly in old code) [] Success, error message integration [x] Data model and UI separation [x] Registries for tools and translation units [] Automatic adaptation - [x] Link adaptation - [x] Reference adaptation - [x] Image adaptation - [] Template adaptation - [] Gallery adaptation - [] Math extension adaptation - [] Poem adaptation - [x] Category adaptation [x] Tool card management system [] Tool cards - [] Link tool : A dummy tool exist, displays adapted target title - [] Dictionary tool - A card exist, appears on text selection. No api to fetch dictionary meaning. - [] Search tool - Tool is present, search is not present - [] Formatting tool - [] Reference tool - Reference card shows adapted reference and a reference removal button works. TODO: adapt refererences that are templates - [] Template tool - [x] Instructions tool [] Template translation system [x] Progress bar widget using OOJS [] Progress calculation integration [] Abuse detection [] Restoring a translation [] Saving a translation [] Publishing translation - [] Building the target page document from data models - [] Conflict checks - [] Cleaning up for clean wikitext [] Translation linting [x] Separation of two codebases using URL switch [] unit tests - Some tests exist, code is written to help easy unit testing.

As preparation for VE, and also as a consolidation of usecases that were patched up over last 2 years, we need to reorganize the classes in better way. It is better to do now before VE integration so that the tech debt does not carry forward. ----------- **Background**: 1. CX was developed iteratively for last 2+ years. During that time, features were added in several stage of product development. In the beginning of the project, there was a highlevel understanding of features but not the details. So the architecture was a flexible one where modules can be plugged and get this done. This worked very well for us and we were able to add features fast. But the approach caused code duplication, less organized hierarchy of similar usecases. So a consolidation and reorganization of these use cases is much needed. 2. The general direction in which CX is moving is to align with the MediaWiki extension good practices which includes OOJS UI based standardised frondend. Also CX need much improved editing experience with the help of VE. OOJS and obvioulsly VE follow object oriented architecture heavily. CX's plugin based and global hooks based architecture is ill suited to mix with them. So the above mentioned organization should follow OO architecture for the best match. 3. The patched up CX code showed some shortcomings recently and we can solve it during this reorganization. This excercise will be done in several iterations and the code in production wont switch to this new codebase till everything is in place. The new codebased will be available with cxx=1 param in URL. **Concepts** Following coding, architecture concepts are followed 1. Data manipulation, adaptation are done in DataModel classes and made independent of UI or contentedtiable elements. Changes in contenteditables are updated in datamodels whenever content changes. 2. Definition of translation unit - Any translatable element which has correspondence in target language, automatically adaptable or manually translatable and editable are defined as TranslationUnit. 3. Clean hierarchy of translation units 4. The translation context is available in Translation Units and other classes by dependency injection. Avoiding the mw.cx globals for context 5. A translation unit can have zero or more translation tools which are tools shown in translation column. 6. All translation units are wrapped in <section> tags 7. Methods to be designed to help unit testing as much as possible 8. OOJS UI widgets 9. Object oriented code arrangement with the help of OOJS **Checklist** [x] Migrate The 3 column based UI frame to OOJS [x] Rewrite the translation source selector using OOJS widgets [x] Define a data model hierarchy - abstract the translation units [x] Source page loading [x] Rendering translatable sections in source column [x] Categories widget migration (https://gerrit.wikimedia.org/r/#/c/333894/) [x] Placeholders for source sections [x] Section alignment on edits [x] Cache management for links, title pairs (New in this version. it did not exist properly in old code) [] Success, error message integration [x] Data model and UI separation [x] Registries for tools and translation units [] Automatic adaptation - [x] Link adaptation - [x] Reference adaptation - [x] Image adaptation - [] Template adaptation - [] Gallery adaptation - [] Math extension adaptation - [] Poem adaptation - [x] Category adaptation [x] Tool card management system [] Tool cards - [] Link tool : A dummy tool exist, displays adapted target title - [] Dictionary tool - A dummy card existcard exist, appears on text selection. No api to fetch dictionary meaning. - [] Search tool - Tool is present, search is not present - [] Formatting tool - [] Reference tool - Reference card shows adapted reference and a reference removal button(noop) works. TODO: adapt refererences that are templates - [] Template tool - [x] Instructions tool [] Template translation system [x] Progress bar widget using OOJS [] Progress calculation integration [] Abuse detection [] Restoring a translation [] Saving a translation [] Publishing translation - [] Building the target page document from data models - [] Conflict checks - [] Cleaning up for clean wikitext [] Translation linting [x] Separation of two codebases using URL switch [] unit tests - Some tests exist, code is written to help easy unit testing.