Change Details

This is the top-level tracker bug for LanguageConverter support in Parsoid. Plan of record, roughly: {icon check color=green} Phase 1: Parse all LC constructs into DOM (and round-trip them). This is sufficient to allow VE to edit LC wikis in same fashion as wikitext editor, w/ mix of variants displayed during editing. Phase 2: Actually run conversion on the DOM, using the parsed constructs. This is sufficient for "read-view" use of Parsoid output, for example in mobile frontend, for google indexing, etc. Phase 3 (speculative): Use selective serialization to allow VE to operate on the converted text. This allows "single variant" editing, without the chaotic mix of variants shown in wikitext editing, and uses selective serialization to preserve the original variant of unedited text. Phase 4 (speculative): Introduce new LC syntax or Glossary features which are a better match for future plans. This would avoid the "from this point forward" behavior of LC rules, which complicates incremental update, as well as avoiding the use of templates as a workaround for per-page glossaries. We might also introduce more pervasive language tagging in the source, to better match LC uses where character set can't be used to distinguish variant (toy example: pig latin -vs- english).

This is the top-level tracker bug for LanguageConverter support in Parsoid. Plan of record, roughly: [x] {icon check color=green} Phase 1: Parse all LC constructs into DOM (and round-trip them). This is sufficient to allow VE to edit LC wikis in same fashion as wikitext editor, w/ mix of variants displayed during editing. [ ] Phase 2: Actually run conversion on the DOM, using the parsed constructs. This is sufficient for "read-view" use of Parsoid output, for example in mobile frontend, for google indexing, etc. [ ] Phase 3 (speculative): Use selective serialization to allow VE to operate on the converted text. This allows "single variant" editing, without the chaotic mix of variants shown in wikitext editing, and uses selective serialization to preserve the original variant of unedited text. [ ] Phase 4 (speculative): Introduce new LC syntax or Glossary features which are a better match for future plans. This would avoid the "from this point forward" behavior of LC rules, which complicates incremental update, as well as avoiding the use of templates as a workaround for per-page glossaries. We might also introduce more pervasive language tagging in the source, to better match LC uses where character set can't be used to distinguish variant (toy example: pig latin -vs- english).

This is the top-level tracker bug for LanguageConverter support in Parsoid. Plan of record, roughly: [x] {icon check color=green} Phase 1: Parse all LC constructs into DOM (and round-trip them). This is sufficient to allow VE to edit LC wikis in same fashion as wikitext editor, w/ mix of variants displayed during editing. [ ] Phase 2: Actually run conversion on the DOM, using the parsed constructs. Phase 2: Actually run conversion on the DOM, using the parsed constructs. This is sufficient for "read-view" use of Parsoid output, for example in mobile frontend, for google indexing, etc. [ ] Phase 3 (speculative): Use selective serialization to allow VE to operate on the converted text. Phase 3 (speculative): Use selective serialization to allow VE to operate on the converted text. This allows "single variant" editing, without the chaotic mix of variants shown in wikitext editing, and uses selective serialization to preserve the original variant of unedited text. [ ] Phase 4 (speculative): Introduce new LC syntax or Glossary features which are a better match for future plans. This would avoid the "from this point forward" behavior of LC rules, which complicates incremental update, as well as avoiding the use of templates as a workaround for per-page glossaries. We might also introduce more pervasive language tagging in the source, to better match LC uses where character set can't be used to distinguish variant (toy example: pig latin -vs- english).