Using i18n of releases/builds #498
Labels
type: improvement
The issue suggests an improvement of an existing feature
Milestone
Comments
|
This isn't supported officially yet... But You can set it on the command line via JVM parameters: |
|
Perhaps a |
|
Good idea! :) |
This was referenced Jan 2, 2017
tofi86
added
the
type: improvement
|
This will probably be implemented with PR #650 in near future. |
rdeltour
pushed a commit
that referenced
this issue
Nov 24, 2018
The locale used by EPUBCheck can now be configured:
- with a `--locale` option on the command line
- with the `setLocale(Locale locale)` method on the `EpubCheck` class
- when no locale is provided, the library will fall back to the default
JVM Locale (i.e. EPUBCheck’s behavior doesn’t change)
This PR introduces the following changes:
- Refactored `com.adobe.epubcheck.util.Messages`:
- new static `getInstance(…)` methods to get the `Messages` instance
for the given (optional) locale and class name (used to resolve
the name of the underlying `ResourceBundle`).
- the `Messages` instances are cached in a table, keyed with locale
codes and resource bundle names.
- Refactored the `com.adobe.epubcheck.message` package:
- `MessageDictionary` is now an interface; it's functionality is split
in several classes to handle default messages, loading of override
files, overridden messages, dumping message files, and severities.
- messages and severities are cached.
- Refactored the `org.idpf.epubcheck.util.css` package, to make it
locale-aware:
- a `Locale` is given as an argument to the `CSSParser` constructor
- the package `Messages` class is removed, replaced by the main
`com.adobe.epubcheck.util.Messages`
- New `LocalizedReport` interface, extending the `Report` interface with
locale getter/setter methods, representing a localizable report.
- the existing `Report` interface is kept unchanged, for backwards
compatibility
- `MasterReport` implements this new `LocalizedReport` interface
- the localization code checks if the underlying report is an instance
of `LocalizedReport` before setting a new locale.
- New `LocaleHolder` facility to statically store the "current" locale
in a thread-local variable. This is used by libraries that cannot be
configured dynamically with a new locale (like Jing).
- Monkey-patch Jing's `Localizer` class to load Jing's resource bundles
for the locale exposed in the `LocaleHolder` utility.
- Expose the current locale in the `ValidationContext` class
- Update the java sources compatibility version to 1.7
- New locale-related tests
Limitations:
- Jing's localization relies on the locale information exposed in a
static thread-local variable (in the `LocaleHolder` class). Any new
implementations of the `LocalizedReport` must make sure that the locale
stored in the `LocaleHolder` is updated when the locale is changed or
initialized.
- The validation messages defined in the schematron schemas are still
not localized.
Thanks to @matthew-macgregor for the original PR contribution (#650)!
Closes #650
Fixes #498
rdeltour
pushed a commit
that referenced
this issue
Nov 25, 2018
The locale used by EPUBCheck can now be configured:
- with a `--locale` option on the command line
- with the `setLocale(Locale locale)` method on the `EpubCheck` class
- when no locale is provided, the library will fall back to the default
JVM Locale (i.e. EPUBCheck’s behavior doesn’t change)
This PR introduces the following changes:
- Refactored `com.adobe.epubcheck.util.Messages`:
- new static `getInstance(…)` methods to get the `Messages` instance
for the given (optional) locale and class name (used to resolve
the name of the underlying `ResourceBundle`).
- the `Messages` instances are cached in a table, keyed with locale
codes and resource bundle names.
- Refactored the `com.adobe.epubcheck.message` package:
- `MessageDictionary` is now an interface; it's functionality is split
in several classes to handle default messages, loading of override
files, overridden messages, dumping message files, and severities.
- messages and severities are cached.
- Refactored the `org.idpf.epubcheck.util.css` package, to make it
locale-aware:
- a `Locale` is given as an argument to the `CSSParser` constructor
- the package `Messages` class is removed, replaced by the main
`com.adobe.epubcheck.util.Messages`
- New `LocalizedReport` interface, extending the `Report` interface with
locale getter/setter methods, representing a localizable report.
- the existing `Report` interface is kept unchanged, for backwards
compatibility
- `MasterReport` implements this new `LocalizedReport` interface
- the localization code checks if the underlying report is an instance
of `LocalizedReport` before setting a new locale.
- New `LocaleHolder` facility to statically store the "current" locale
in a thread-local variable. This is used by libraries that cannot be
configured dynamically with a new locale (like Jing).
- Monkey-patch Jing's `Localizer` class to load Jing's resource bundles
for the locale exposed in the `LocaleHolder` utility.
- Expose the current locale in the `ValidationContext` class
- Update the java sources compatibility version to 1.7
- New locale-related tests
Limitations:
- Jing's localization relies on the locale information exposed in a
static thread-local variable (in the `LocaleHolder` class). Any new
implementations of the `LocalizedReport` must make sure that the locale
stored in the `LocaleHolder` is updated when the locale is changed or
initialized.
- The validation messages defined in the schematron schemas are still
not localized.
Thanks to @matthew-macgregor for the original PR contribution (#650)!
Closes #650
Fixes #498
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
How can the i18n of releases/builds be used? Neither the readme nor the Wiki nor the --help command line argument seem to give a hint how to switch to another language.
The text was updated successfully, but these errors were encountered: