Text part language: Add Support For Block Elements

[mmichaelis]

📝 Provide a description of the improvement

Project Challenge

• Just as in HTML, our data representation allows setting the lang attribute not only for <span> but for inline elements such as <em>, <strong> and for block elements such as <p>, <blockquote>, <table>, <tr>, and so on.

• CKEditor is only one possible source of these data, thus, we have to deal with various states which are considered valid XML (according to our custom grammar).

• The text part language feature supports only lang attribute for <span>.

Suggested Improvement

• It should be possible to define at least languages also for block elements. If no text is selected, the language is instead applied to the next matching outer block element.

• This would also match the description of the text part language feature much better:

  This feature is especially useful when your content includes text sections written in different text directions, e.g. when the whole content is written in English but includes some citations in Arabic.

  Exactly the described use-case (strictly following the description) cannot be modelled. It always means, that the block (here: the citation) has to contain a <span> which then sets the language.

  Luckily, while editing in CKEditor 35.x only, the difference is almost impossible to detect. E.g., when adding a new paragraph to a blockquote, it automatically also copies the language span from the previous paragraph.

• Caveat: It will break the feature select language without selection and continue typing, i.e., select the language prior to adding contents in the given language at current cursor position. For compatibility reasons, it would at least require a configuration option. Like: If no surrounding block elements exist matching some allowlist (which by default is empty), a new <span> is opened instead to fulfill the previous behavior. Example configuration suggestion:

  language: {
  ui: editorLanguage,
  content: "en",
  textPartLanguage: {
    preferBlock: [
      "p", "blockquote", "table", "ol", "ul",
    ],
    // Alternative idea: Just prefer any outer block element:
    preferBlock: true,
    languages: [
      { title: "Arabic", languageCode: "ar", textDirection: "rtl" },
      { title: "English (GB)", languageCode: "en-GB" },
      { title: "English (US)", languageCode: "en-US" },
      { title: "German", languageCode: "de" },
    ],
  },
  },

  Suggestion for the allowlist would also to give it some priority:

  // For <blockquote><p> prefer adding language to blockquote:
  preferBlock: [ "blockquote", "p" ],
  // For <blockquote><p> prefer adding language to <p>:
  preferBlock: [ "p", "blockquote" ],

Caveat

This approach still would struggle with examples, such as (in data/data view):

<ol><li lang="en">Lorem</li></ol>
<table lang="en"><tr><td>Lorem</td></tr></table>
<table><tr lang="en"><td>Lorem</td></tr></table>
<table><tr><td lang="en">Lorem</td></tr></table>

Workaround for not having the suggested improvement

• Inline Elements: In data processing, we can split <em lang="en"> to <em><span lang="en"> and with some extra effort processing from data view to data, we could handle cases such as:

  <!-- Data View -->
  <em><span lang="en">Hello</span></em>
  <!-- Data -->
  <em lang="en">Hello</em>
  
  <!-- Data View -->
  <em><span lang="en">Hello</span> World!</em>
  <!-- Data -->
  <em><span lang="en">Hello</span> World!</em>

• Block Elements: While the workaround above may also work for simple nested use-cases (such as <p lang="en">Hello</p> to <p><span class="en">Hello</span></p>, it will fail (or get much more complex) to provide a good mapping for example for data such as:

  <!-- Data -->
  <table lang="en"><tr><td>Hello</td></tr><table>
  <!-- Data View (hard or even impossible to restore to data again) -->
  <table><tr><td><span lang="en">Hello</span></td></tr><table>
  
  <!-- Data -->
  <ul lang="en"><li>Hello</li><ul>
  <!-- Data View (hard or even impossible to restore to data again) -->
  <ul lang="en"><li><span lang="en">Hello</span></li><ul>

  Only option up to now for toData processing: Look up all nested <span> elements, if they all carry the same language and any text node is wrapped by them. Then, remove these spans and add the language to the corresponding block element. And for toDataView processing, to take the language from the block element and wrap all text nodes within into corresponding spans.

📃 Other details

• Browser: Chrome
• OS: Windows
• CKEditor version: 35.2.0
• Installed CKEditor plugins: Text part language

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).

[bkosborne]

+1 to this. An issue with the current language parts implementation is that it only works with spans. But if you specify an RTL language, it adds the "dir" attribute to the span, and browsers won't actually render the language in that direction because span is an inline element. The dir attribute seems to only have default alignment behavior for block elements like a p.