Существует ли полуавтоматический способ извлечения строк для i18n? - PullRequest
13 голосов
/ 18 июня 2009

У нас есть проект Java, который содержит большое количество англоязычных строк для пользовательских запросов, сообщений об ошибках и так далее. Мы хотим извлечь все переводимые строки в файл свойств, чтобы их можно было перевести позже.

Например, мы хотели бы заменить:

Foo.java

String msg = "Hello, " + name + "! Today is " + dayOfWeek;

с:

Foo.java

String msg = Language.getString("foo.hello", name, dayOfWeek);

language.properties

foo.hello = Hello, {0}! Today is {1}

Я понимаю, что сделать это полностью автоматизированным способом практически невозможно, так как не каждая строка должна быть переведена. Однако нам было интересно, существует ли полуавтоматический способ, который устраняет часть трудоемкости.

Ответы [ 8 ]

4 голосов
/ 26 августа 2009

То, что вам нужно, - это инструмент, который заменяет каждое выражение, включающее конкатенацию строк, вызовом библиотеки, с очевидным особым случаем выражений, включающим только одну литеральную строку.

Система преобразования программ, в которой вы можете выразить желаемые шаблоны, может сделать это. Такая система принимает правила в виде:

         lhs_pattern -> rhs_pattern  if condition ;

где шаблоны - это фрагменты кода с ограничениями синтаксической категории для переменных шаблона. Это заставляет инструмент искать синтаксис, совпадающий с lhs_pattern, и, если он найден, заменить на rhs_pattern, где сопоставление с образцом выполняется по структурам языка, а не по тексту. Так что он работает независимо от форматирования кода, отступов, комментариев и т. Д.

Зарисовка нескольких правил (и упрощение для краткости) следуя стилю вашего примера:

  domain Java;

  nationalize_literal(s1:literal_string):
    " \s1 " -> "Language.getString1(\s1 )";

  nationalize_single_concatenation(s1:literal_string,s2:term):
    " \s1 + \s2 " -> "Language.getString1(\s1) + \s2"; 

  nationalize_double_concatenation(s1:literal_string,s2:term,s3:literal_string): 
      " \s1 + \s2 + \s3 " -> 
      "Language.getString3(\generate_template1\(\s1 + "{1}" +\s3\, s2);"
   if IsNotLiteral(s2);

Шаблоны сами заключены в "..."; это не строковые литералы Java, а скорее способ сказать многоязычному механизму сопоставления с образцом что суффиксом внутри "..." является (домен) Java-код. Мета-вещи помечены \, например, мета-переменные \ s1, \ s2, \ s3 и встроенный шаблон вызывают \ generate с помощью (и) для обозначения своего списка мета-параметров: -}

Обратите внимание на использование ограничений категории синтаксиса для мета-переменных s1 и s3 для обеспечения соответствия только строковых литералов. То, что метапеременные совпадают на левой стороне шаблона, подставляется на правой стороне.

Под-шаблон generate_template - это процедура, которая во время преобразования (например, при срабатывании правила) оценивает свой первый известный аргумент как постоянный в строку шаблона, которую вы предложили, вставляет в вашу библиотеку и возвращает библиотеку строковый индекс. Обратите внимание, что первый аргумент для генерации шаблона в этом примере полностью состоит из конкатенации буквенных строк.

Очевидно, что кому-то придется вручную обрабатывать шаблонные строки, которые попадают в библиотеку, чтобы получить эквиваленты на иностранных языках.
Вы правы в том, что это может привести к чрезмерной шаблонизации кода, потому что некоторые строки не должны помещаться в национализированную библиотеку строк. В той степени, в которой вы можете написать программные проверки для этих случаев, они могут быть включены в правила в качестве условий для предотвращения их запуска. (Приложив немного усилий, вы можете поместить нетрансформированный текст в комментарий, упрощая отдельные преобразования позже).

Реально, я думаю, вам нужно кодировать ~ ~ 100 таких правил, чтобы охватить комбинаторику и особые случаи интересов. Выгода в том, что ваш код автоматически улучшается. Если все сделано правильно, вы можете применить это преобразование к своему коду несколько раз, так как ваш код проходит несколько выпусков; он оставил бы ранее национализированные выражения в одиночестве и просто пересмотрел бы новые, вставленные «счастливчиками».

Системой, которая может сделать это, является DMS Software Reengineering Toolkit . DMS может анализировать / сопоставлять с образцом / преобразовывать / prettyprint многие языки, включая Java и C #.

2 голосов
/ 19 июня 2009

Eclipse будет выводить каждую отдельную строку и не будет автоматически производить подстановку, как вы ищете. Если у вас есть очень непротиворечивое соглашение о том, как вы строите свои строки, вы можете написать Perl-скрипт для разумной замены файлов .java. Но этот скрипт станет довольно сложным, если вы захотите обработать

  • String msg = new String ("Hello");
  • String msg2 = "Hello2";
  • String msg3 = new StringBuffer (). Append ("Hello3"). ToString ();
  • String msg4 = "Hello" + 4;
  • и т.д.

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

EDIT: Инструмент был Globalyzer от Lingport. Веб-сайт говорит, что поддерживает экстернализацию строк, но не конкретно как Не уверен, поддерживает ли он подстановку переменных. Существует бесплатная пробная версия, так что вы можете попробовать и посмотреть.

1 голос
/ 10 декабря 2009

Globalyzer обладает обширными возможностями по обнаружению, управлению и экстернализации строк и значительно ускоряет работу, просматривая строки и выводя их одну за другой. Вы можете фильтровать строки, а также видеть их в контексте, а затем либо выводить их по очереди, либо в пакетном режиме. Он работает для широкого спектра языков программирования и типов ресурсов, в том числе и для Java. Плюс Globalyzer находит гораздо больше, чем встроенные строки для ваших проектов интернационализации. Вы можете прочитать больше на http://lingoport.com/globalyzer, и там есть ссылки, чтобы зарегистрировать демо-счет. Globalyzer был изначально создан для выполнения крупных проектов по интернационализации услуг, а затем с годами превратился в полноценный корпоративный инструмент для обеспечения того, чтобы разработка развивалась и оставалась интернационализированной.

1 голос
/ 25 августа 2009

Помимо экранизатора строк Eclipse , который генерирует файлы свойств, Eclipse имеет предупреждение о неэкстернализованных строках, что полезно для поиска файлов, которые вы не интернационализировали.

String msg = "Hello " + name;

выдает предупреждение «Неэкстернализованный строковый литерал; после него следует // $ NON-NLS- $». Для строк, которые действительно принадлежат к коду, вы можете добавить аннотацию (@SuppressWarnings("nls")) или добавить комментарий:

String msg = "Hello " + name; //$NON-NLS-1$

Это очень полезно для преобразования проекта в правильную интернационализацию.

0 голосов
/ 28 августа 2009

, так как все весят в IDE, я думаю, мне лучше постоять за Netbeans :)

Инструменты -> Интернационализация -> Мастер интернационализации

очень удобно ..

0 голосов
/ 26 августа 2009

Вы можете использовать метод "Externalize String" из eclipse. Откройте файл Java в редакторе, а затем нажмите «Externalize String» в главном меню «Source». ИТ-специалист создает для вас файл свойств со всеми параметрами, выбранными вами при выборе.

Надеюсь, это поможет.

0 голосов
/ 26 августа 2009

Идея InteliJ - это еще один инструмент, который имеет эту функцию.

alt text

Вот ссылка на демо

0 голосов
/ 18 июня 2009

Я думаю, что у eclipse есть возможность вывести все строки в файл свойств.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...