-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
The issue suggests an improvement of an existing feature
label
Jan 2, 2017
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
fradelycodes
added a commit
to fradelycodes/epubcheck
that referenced
this issue
Nov 11, 2024
## Pull Request: Validation Corrections ### Description This pull request includes several corrections to improve the validation process in EPUBCheck. The changes address various issues identified during the validation of EPUB files. ### Changes Made - Corrected validation logic for EPUB version detection. - Improved error handling for invalid `dc:identifier` UUIDs. - Updated the validation rules for `--version` and `-version` command line options. - Enhanced file extension checks to include non-`.epub` files. - Adjusted the reporting of `file://` URLs to `INFO` level. ### Related Issues - Closes w3c#650 - Closes w3c#498 - Closes w3c#853 - Closes w3c#743 - Closes w3c#490 - Closes w3c#289 ### Testing - Added unit tests to cover the new validation rules. - Verified that the changes do not introduce any regressions. ### Additional Notes - Please review the changes and provide feedback. - Contributions from the community are welcome to further improve the validation process. Thank you for your support and contributions to EPUBCheck! --- **Contributors:** - @fradelycodes
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: