Feature request: case-insensitive mapping of Asciidoctor language names to Confluence language names

[xorcus]

Please note that language names supported by Asciidoctor are case-insensitive and slightly differ from Confluence languages.

For this reason, I would kindly ask to consider the following correction to files in: confluence-publisher/asciidoc-confluence-publisher-converter/src/main/resources/org/sahli/asciidoc/confluence/publisher/converter/templates/

templates/helpers.rb:

  def map_to_confluence_supported_lang(lang)
    # Mapping of Asciidoctor language names to Confluence language names
    mapping = {
      'html' => 'xml',
      'javascript' => 'js',
      'json' => 'js',
      'yaml' => 'yml'
    }
    # make the language mapping case-insensitive
    mapping[lang&.downcase] || lang&.downcase
  end

templates/block_listing.html.slim:

    - if (confluence_supported_lang "#{map_to_confluence_supported_lang source_lang}")
      ac:parameter ac:name="language" #{map_to_confluence_supported_lang source_lang}

[cstettler]

Hi @xorcus, thank you for opening this issue. Would you have any reference available that describe that source language values are case-insensitive? The only reference I found was the description of the built-in attribute source-language on https://asciidoctor.org/docs/user-manual/#builtin-attributes, and there, it states that the value has to be in lowercase.

Also, I was not able to find a list of supported values for the source language that would allow an exhaustive mapping of AsciiDoc to Confluence source languages. Do you maybe have any reference for that? Thank you!

[xorcus]

You are right, the specs state it should be specified in lower case. I have tested this behavior with Asciidoctor by creating examples using HTML and html. Both worked with Code Ray, but not with Confluence Publisher (due to the Slim template impl. expecting lower case). In my opinion, treating the source language as case-insensitive makes the tool more user-friendly, especially because in this case it can be handled correctly regardless of the case.

I believe the list of languages supported by Asciidoctor source highlighter depends on the actual highlighter being used (source-highlighter attribute from issue #216).

For example, for Code Ray, Asciidoctor lists the languages here: https://asciidoctor.org/docs/user-manual/#coderay And Code Ray docs also have a list: http://coderay.rubychan.de/

For an exhaustive mapping, one would have to look into each supported highlighter. I personally experiment a bit with a range of languages relevant for my use case and come up with conclusions about what works and what does not.

As for the Confluence, I would look for the languages supported by the Code Block Macro: https://confluence.atlassian.com/doc/code-block-macro-139390.html I have mapped html to xml for Confluence. If I recall well, using html did not work for me in Confluence, or I inspected the "wiki" source code and found out what was used internally.

In addition, Code Ray supports JSON as language, but there is no JSON language in Confluence Code Block Macro docs. Of course, it can be conveniently mapped to JavaScript which behaves as expected, hence the mapping.

[lyca]

Out of the list of supported code formats, matlab is missing. -> https://confluence.atlassian.com/doc/code-block-macro-139390.html

An extensive list of supported language aliases is maintained at highlight.js -> https://github.com/highlightjs/highlight.js/blob/main/SUPPORTED_LANGUAGES.md

Taken into account, this would lead to the following mapping:

def map_to_confluence_supported_lang(lang)
    # Mapping of Asciidoctor/highlight.js language names to Confluence language names
    mapping = {
      'actionscript' => 'actionscript3', 'as' => 'actionscript3',
      'osascript' => 'applescript', 
      'sh' => 'bash', 'zsh' => 'bash', 
      'csharp' => 'c#', 'cs' => 'c#', 
      'hpp' => 'cpp', 'cc' => 'cpp', 'hh' => 'cpp', 'c++' => 'cpp', 'h++' => 'cpp', 'cxx' => 'cpp',  'hxx' => 'cpp',
      'dpr' => 'delphi', 'dfm' => 'delphi', 'pas' => 'delphi', 'pascal' => 'delphi',
      'patch' => 'diff',
      'erlang' => 'erl',
      'html' => 'xml', 'xhtml' => 'xml', 'rss' => 'xml', 'atom' => 'xml', 'xjb' => 'xml', 'xsd' => 'xml', 'xsl' => 'xml', 'plist' => 'xml', 'svg' => 'xml',
      'jsp' => 'java',
      'javascript' => 'js', 'jsx' => 'js', 'json' => 'js'
      'pl' => 'perl', 'pm' => 'perl',
      'plaintext' => 'text', 'txt' => 'text',
      'ps' => 'powershell', 'ps1' => 'powershell',
      'python' => 'py', 'gyp' => 'py',
      'rb' => 'ruby', 'gemspec' => 'ruby', 'podspec' => 'ruby', 'thor' => 'ruby', 'irb' => 'ruby',
      'vbnet' => 'vb', 'vbscript' => 'vb', 'vbs' => 'vb',
      'yaml' => 'yml'
    }
    # make the language mapping case-insensitive
    mapping[lang&.downcase] || lang&.downcase
  end

[cstettler]

Thank you @lyca for your contribution. Even though it does not add support for mapping language names in a case-insensitive way as requested by the issue, it adds value by mapping to the corresponding Confluence language names. I therefore consider this issue as fixed after merging the pull request (as state in PR #360). @xorcus, please feel free to re-open the issue if that's not yet valuable enough for your use case.