nxml-mode: Could we support new XML schemas?

nxml-mode: Could we support new XML schemas?

[Kevin Vigouroux via Emacs development discussions.]

nxml-mode only supports Relax NG Compact. The tools for converting from
one schema to another don't seem reliable to me: it seems to me that
they were created a decade ago and are now held at lambda locations (URL).

I would have liked Emacs (e.g., nxml-mode) to be able to validate
documents in XLIFF v2.1 or later [0]. It would seem that this would
require support for multiple schemas to enable an advanced validation
([1]: “NVDL Mapping Script”, page 194).

I am waiting for your comments to know what can be done.

[0] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff
[1] https://ulir.ul.ie/bitstream/handle/10344/6105/Saadatfar_2017_examining.pdf?sequence=6
-- 
Best regards,
Kevin Vigouroux

Re: nxml-mode: Could we support new XML schemas?

[Stefan Monnier]

> I would have liked Emacs (e.g., nxml-mode) to be able to validate
> documents in XLIFF v2.1 or later [0]. It would seem that this would
> require support for multiple schemas to enable an advanced validation
> ([1]: “NVDL Mapping Script”, page 194).

That would be nice, indeed.


        Stefan

Re: nxml-mode: Could we support new XML schemas?

[Kevin Vigouroux via Emacs development discussions.]

Potentially, we could integrate features that allow Emacs to compete
with other translation tools for software development.
-- 
Best regards,
Kevin Vigouroux

Re: nxml-mode: Could we support new XML schemas?

[Jean-Christophe Helary]

> On Sep 25, 2021, at 13:13, Kevin Vigouroux via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> 
> Potentially, we could integrate features that allow Emacs to compete
> with other translation tools for software development.

Kevin,

There is a thread on help-emacs-gnu regarding that:

https://lists.gnu.org/archive/html/help-gnu-emacs/2020-05/msg00168.html

The current PO-mode could probably work with XLIFF, but that would not be sufficient to make Emacs "compete" with other translation tools, even if the point of comparison is what exists under the GPL: OmegaT for ex.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: nxml-mode: Could we support new XML schemas?

[Kevin Vigouroux via Emacs development discussions.]

XLIFF documents are validated using XML schemas. These schemas are
currently not supported by Emacs.

I think I’ve found a way, but Emacs needs to support XLIFF first (XML
mode + validation schema).
-- 
Best regards,
Kevin Vigouroux

Re: nxml-mode: Could we support new XML schemas?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > XLIFF documents are validated using XML schemas. These schemas are
  > currently not supported by Emacs.

Is there other free software that can do this?
Emacs could invoke it in a subprocess.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: nxml-mode: Could we support new XML schemas?

[Kevin Vigouroux via Emacs development discussions.]

Richard Stallman <rms@gnu.org> writes:

>   > XLIFF documents are validated using XML schemas. These schemas are
>   > currently not supported by Emacs.
>
> Is there other free software that can do this?
> Emacs could invoke it in a subprocess.

LemMinX [1] is released under the Eclipse Public License 2.0. It
depends on Eclipse LSP4J (license EPL 2.0 [2]). This LSP server 
is used by an Emacs LSP mode (lsp-mode).

[1] https://github.com/eclipse/lemminx/blob/master/LICENSE
[2] https://github.com/eclipse/lsp4j/blob/main/LICENSE
---
Best regards,
Kevin Vigouroux

Re: nxml-mode: Could we support new XML schemas?

[Jean-Christophe Helary]

> On Sep 28, 2021, at 17:10, Kevin Vigouroux via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> 
> Richard Stallman <rms@gnu.org> writes:
> 
>>> XLIFF documents are validated using XML schemas. These schemas are
>>> currently not supported by Emacs.
>> 
>> Is there other free software that can do this?
>> Emacs could invoke it in a subprocess.
> 
> LemMinX [1] is released under the Eclipse Public License 2.0. It
> depends on Eclipse LSP4J (license EPL 2.0 [2]). This LSP server 
> is used by an Emacs LSP mode (lsp-mode).
> 
> [1] https://github.com/eclipse/lemminx/blob/master/LICENSE
> [2] https://github.com/eclipse/lsp4j/blob/main/LICENSE

All the applications from Maxprograms are Eclipse 1.0 licensed.
The developer is the editor of the current XLIFF standard (2.2), along with being a top class expert in the localization area.

https://maxprograms.com/products/index.html

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Emacs as an XLIFF editor

[Kevin Vigouroux via Emacs development discussions.]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

>> On Sep 28, 2021, at 17:10, Kevin Vigouroux via Emacs development discussions. <emacs-devel@gnu.org> wrote:
>> 
>> Richard Stallman <rms@gnu.org> writes:
>> 
>>>> XLIFF documents are validated using XML schemas. These schemas are
>>>> currently not supported by Emacs.
>>> 
>>> Is there other free software that can do this?
>>> Emacs could invoke it in a subprocess.
>> 
>> LemMinX [1] is released under the Eclipse Public License 2.0. It
>> depends on Eclipse LSP4J (license EPL 2.0 [2]). This LSP server 
>> is used by an Emacs LSP mode (lsp-mode).
>> 
>> [1] https://github.com/eclipse/lemminx/blob/master/LICENSE
>> [2] https://github.com/eclipse/lsp4j/blob/main/LICENSE
>
> All the applications from Maxprograms are Eclipse 1.0 licensed.  The
> developer is the editor of the current XLIFF standard (2.2), along
> with being a top class expert in the localization area.
>
> https://maxprograms.com/products/index.html

Yes, but the idea is to be able to parse the sources of the programming
languages supported by Emacs. I don't know if it's possible, but then,
from the parsing, build the XLIFF file.

The final goal is to design a translation application inside Emacs. In
this case, Emacs should also edit the XLIFF file. OpenXLIFF Filters
can’t do that [1].

[1] https://maxprograms.com/products/openxliff.html
-- 
Best regards,
Kevin Vigouroux

Re: Emacs as an XLIFF editor

[Jean-Christophe Helary]

> On Sep 28, 2021, at 22:29, Kevin Vigouroux via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> 
> Jean-Christophe Helary <lists@traduction-libre.org> writes:
> 
>>> On Sep 28, 2021, at 17:10, Kevin Vigouroux via Emacs development discussions. <emacs-devel@gnu.org> wrote:
>>> 
>>> Richard Stallman <rms@gnu.org> writes:
>>> 
>>>>> XLIFF documents are validated using XML schemas. These schemas are
>>>>> currently not supported by Emacs.
>>>> 
>>>> Is there other free software that can do this?
>>>> Emacs could invoke it in a subprocess.
>>> 
>>> LemMinX [1] is released under the Eclipse Public License 2.0. It
>>> depends on Eclipse LSP4J (license EPL 2.0 [2]). This LSP server 
>>> is used by an Emacs LSP mode (lsp-mode).
>>> 
>>> [1] https://github.com/eclipse/lemminx/blob/master/LICENSE
>>> [2] https://github.com/eclipse/lsp4j/blob/main/LICENSE
>> 
>> All the applications from Maxprograms are Eclipse 1.0 licensed.  The
>> developer is the editor of the current XLIFF standard (2.2), along
>> with being a top class expert in the localization area.
>> 
>> https://maxprograms.com/products/index.html
> 
> Yes, but the idea is to be able to parse the sources of the programming
> languages supported by Emacs. I don't know if it's possible, but then,
> from the parsing, build the XLIFF file.

Programming languages supported by emacs already have gettext, documentation has po4a, and PO is a robust enough format. I'm not sure how using XLIFF for them would add any value to the process. Also there are PO/XLIFF round-trip converters already.

Creating a translation file and parsing/translating it are 2 very different processes and if the goal is to design a translation application inside Emacs, then creating PO/XLIFF files is fully outside the scope.

There are already plenty of very robust filters/converters that accomplish that already.

> The final goal is to design a translation application inside Emacs. In
> this case, Emacs should also edit the XLIFF file.

I understand that. May I suggest that you read the thread that I mentioned earlier if you've not done so already? If that is the goal, the main task is indeed to properly *edit* the XLIFF file, and probably the way the PO mode does that for PO can be used as a base.

> OpenXLIFF Filters can’t do that [1].

I never suggested that OpenXLIFF could do that. Maxprograms’ XLIFF editor is Swordfish. OpenXLIFF is just the filtering/conversion part.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs as an XLIFF editor

[Kevin Vigouroux via Emacs development discussions.]

Let’s say that the framework offered by the XLIFF 2 specification is
broader than gettext.

#+begin_quote
- Agent :: any application or tool that generates (creates), reads,
  edits, writes, processes, stores, renders or otherwise handles XLIFF
  Documents.

  Agent is the most general application conformance target that
  subsumes all other specialized user agents disregarding whether they
  are defined in this specification or not.
#+end_quote

#+begin_quote
While the primary focus is on being a lossless interchange format, usage
of XLIFF as a processing format is neither encouraged nor discouraged or
prohibited.
#+end_quote

Could we reuse existing features to get _something else_?

XLIFF could be used as a standardized template to store data in a
structured way. For example, Font Lock mode apply an appropriate
formatting in a buffer using a syntax table.

About the XLIFF edition, I mixed two kinds of editions: 
by the user or processes. Here both are useful.

In my opinion, the PO mode is not useful in this workflow.
-- 
Best regards,
Kevin Vigouroux

Re: nxml-mode: Could we support new XML schemas?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > LemMinX [1] is released under the Eclipse Public License 2.0. It
  > depends on Eclipse LSP4J (license EPL 2.0 [2]). This LSP server 
  > is used by an Emacs LSP mode (lsp-mode).

Their incompatible license is a drawback, but not a fatal one.
If using those programs would avoid a lot of work, let's do so.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: About XLIFF validation

[Kevin Vigouroux via Emacs development discussions.]

James Clark (the author of the nXML mode and the Trang conversion tool)
told me, after sending him a message, that I could do the conversion
myself. But I don’t know how to install and configure Trang, so it would
be nice if someone could do it for me.

The schemas to validate an XLIFF document are available at the URL:
https://github.com/oasis-tcs/xliff-xliff-22/tree/master/xliff-21/schemas

You can find examples of XLIFF documents at the URL:
https://github.com/GALAglobal/TAPICC/tree/master/extraction_examples
-- 
Best regards,
Kevin Vigouroux

Re: About XLIFF validation

[Jean-Christophe Helary]

> On Sep 29, 2021, at 16:51, Kevin Vigouroux via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> 
> James Clark (the author of the nXML mode and the Trang conversion tool)
> told me, after sending him a message, that I could do the conversion
> myself. But I don’t know how to install and configure Trang, so it would
> be nice if someone could do it for me.

https://relaxng.org/jclark/trang.html

everything you need to know is there.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: About XLIFF validation

[Kevin Vigouroux via Emacs development discussions.]

I built Trang as specified, but in the end, Trang does not support XSD
as an input format. Back to the starting point.
-- 
Best regards,
Kevin Vigouroux

Re: About XLIFF validation

[Jean-Christophe Helary]

> On Sep 29, 2021, at 21:20, Kevin Vigouroux via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> 
> I built Trang as specified, but in the end, Trang does not support XSD
> as an input format. Back to the starting point.

Maybe you should mention that to James Clark ?


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

XLIFF Core RNC Schema

[Kevin Vigouroux via Emacs development discussions.]

[-- Attachment #1: XLIFF Core RNC Schema --]
[-- Type: application/relax-ng-compact-syntax, Size: 7394 bytes --]

[-- Attachment #2: Type: text/plain, Size: 282 bytes --]


I have delivered the XLIFF Core RNC schema as an attachment. This should
be enough for testing.

N.B.: File generated via Trang from the source file
http://tools.oasis-open.org/version-control/browse/wsvn/xliff/branches/Soroush/xliff_core_2.0.rng
-- 
Best regards,
Kevin Vigouroux