Как удалить местоположение, исходный файл и номер строки из автоматически созданного файла XLIFF Angular 6?

Мы используем встроенные инструменты Angular для извлечения сообщений из шаблонов.

Это отлично работает, и мы получаем всю информацию в файле XLIFF, используя:

ng xi18n

В этом файле trans-unit выглядит так:

<trans-unit id="3535a6c8296b457542000d2cbd15ca93f86cdd79" datatype="html">
    <source>Homepage</source>
    <context-group purpose="location">
      <context context-type="sourcefile">app/component/nav/nav.component.html</context>
      <context context-type="linenumber">39</context>
    </context-group>
    <note priority="1" from="description">description</note>
    <note priority="1" from="meaning">title</note>
</trans-unit>

Несмотря на то, что содержание в <context-group purpose="location"> выглядит интересно, оно раскрывает детали проекта и реализации во внешней службе перевода.

Есть ли способ указать Angular не включать эту информацию в XLIFF-файл?

В качестве альтернативы, есть ли другие инструменты, которые могли бы выполнить преобразование? Возможно, компилятору важно иметь эту информацию во время сборки.


person lampshade    schedule 20.02.2019    source источник


Ответы (2)


Следующий код Angular генерирует эти строки (проверьте полный исходный код на Github):

const _CONTEXT_GROUP_TAG = 'context-group';
const _CONTEXT_TAG = 'context';

// http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html
// http://docs.oasis-open.org/xliff/v1.2/xliff-profile-html/xliff-profile-html-1.2.html
export class Xliff extends Serializer {
  write(messages: i18n.Message[], locale: string|null): string {
    const visitor = new _WriteVisitor();
    const transUnits: xml.Node[] = [];

    messages.forEach(message => {
      let contextTags: xml.Node[] = [];
      message.sources.forEach((source: i18n.MessageSpan) => {
        let contextGroupTag = new xml.Tag(_CONTEXT_GROUP_TAG, {purpose: 'location'});
        contextGroupTag.children.push(
            new xml.CR(10),
            new xml.Tag(
                _CONTEXT_TAG, {'context-type': 'sourcefile'}, [new xml.Text(source.filePath)]),
            new xml.CR(10), new xml.Tag(
                                _CONTEXT_TAG, {'context-type': 'linenumber'},
                                [new xml.Text(`${source.startLine}`)]),
            new xml.CR(8));
        contextTags.push(new xml.CR(8), contextGroupTag);
      });

      [...]

Основываясь на моем анализе кода, кажется, что нет способа сказать Angular, чтобы он не включал эту информацию в XLIFF-файл. НО эти сгенерированные строки, похоже, больше нигде не используются. Я полагаю, это просто для согласования с Характеристики XLIFF.

Вероятно, вы могли бы удалить его с помощью скрипта (например, у @Maryannah), не нарушая Angular.

person youri    schedule 28.06.2019

Вы не должны удалять их, так как Angular нуждается в этом для перевода.

Но если это то, что вы хотите, вы можете использовать JS-скрипт для их удаления:

const fs = require('fs');
const data = fs.readFileSync('./i18n.xliff').toString();
const contentToRemoveRegexp = /<context-group purpose="location">([.\s\S])*<\/context-group>/g;
const replaced = data.replace(contentToRemoveRegexp, '');
fs.writeFileSync('./i18n-updated.xliff', replaced);

сохраните его в любом файле JS, который вы хотите, и создайте скрипт в файле пакета:

"i18n:update": "ng xi18n && node path/to/your/script/js"
person Community    schedule 25.06.2019
comment
Спасибо за Ваш ответ. У вас есть ссылка на информацию о том, что эти строки необходимы для правильной компиляции Angular? - person lampshade; 26.06.2019
comment
И спасибо за предложенный сценарий. Но если вы говорите, что эти строки необходимы для успешной сборки, я думаю, они должны присутствовать в окончательном оригинале и во всех переведенных файлах. Таким образом, простое удаление контента не сработает, и нам нужен скрипт, который трансформирует версию с context-group и без нее. Правильно? - person lampshade; 26.06.2019
comment
Нет, у меня нет ссылки, извините, это мое собственное утверждение: я уверен, что если вы удалите их, Angular не сможет перевести, так как они говорят ему, где найти заполнитель для перевода! Но ваша проблема похожа на проблему XY: зачем вам вообще это делать? - person ; 26.06.2019
comment
Ну, как я написал в вопросе: Мы отправляем эти файлы XLIFF во внешний сервис перевода. И эта информация в context-group exploid/ раскрывает весь проект и структуру шаблона третьей стороне. Я не уверен, хорошо ли это. - person lampshade; 26.06.2019
comment
Ну, если они не получат структуру вашего приложения, нет, в этом нет ничего страшного. И я имею в виду, вы платите им за эту работу, и если они попытаются вас обмануть, у вас есть преимущество! Кроме того, это служба перевода, они, вероятно, используют специальное программное обеспечение для этого, они даже не смогут прочитать такой файл (не говоря уже о том, чтобы понять его...). Наконец, это обычный HTML, который не раскрывает никакой бизнес-логики или технических лазеек, так что я бы сказал, что вы в безопасности. - person ; 26.06.2019
comment
Если вы действительно опасаетесь, что @lampshade, рассмотрите возможность извлечения всех переводов в другой файл, отправьте его им, а затем примените эти переводы к своему собственному переведенному файлу: это утомительно, трудно автоматизировать, но, по крайней мере, вы будете спокойны. ! - person ; 26.06.2019
comment
Мы также удаляем весь контекст из файлов xlf с помощью скрипта, у нас нет проблем с отсутствующим контекстом для процесса сборки, и у нас есть несколько тысяч переводов. Большая проблема обычно возникает, когда переводчики начинают добавлять html-теги к переводам, которые не подготовлены для дополнительных тегов. Мы также сортируем переводы по их исходному значению, чтобы их было легче проверять при PR-обзоре. - person Xesenix; 28.06.2019
comment
немного изменил регулярное выражение, чтобы очистить также лишние многострочные, вы можете увидеть код здесь: https://github.com/OpenMAVN/MAVN.FrontEnd.BackOffice/blob/master/i18n-clear.js - person Cyclion; 18.04.2020