-
Notifications
You must be signed in to change notification settings - Fork 457
Implementation of msgcat and msgmerge utilities from GNU gettext #1161
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
base: master
Are you sure you want to change the base?
Conversation
…pybabel * Define the MessageConcatenation class to mimic the functionality of GNU gettext's msgcat * Define the MessageMerge class to mimic the functionality of GNU gettext's msgmerge * Implement placeholders for the main interface functions
* Add validation for main msgcat options - input_files, output_file * Temporarily set use_first option to true to avoid handling cases with different translations for the same messages
* Implement options unique, less-than, and more-than, and validate their dependencies with each other. * These options specify which messages to include in the output file. * Implement and validate options no-wrap and width. * Create a helper function _prepare that collects data on message occurrences across different catalogs. * Mark options that are already implemented #
* Implement basic functionality of msgmerge * Use and validate the main options: input-files and output-file * Use and validate options: no-wrap and width * Use and validate options: sort-output and sort-by-file, both in msgmerge and msgcat * In the basic version of working with a compendium, a translation for a message is taken from the compendium only if the resulting catalog lacks a translation.
* Create basic tests to verify the functionality of msgcat, specifically the concatenation of catalogs, merging of message flags, locations, etc. * Remove the validation of options sort-output, sort-by-file, unique, use-first, as they are initialized in the function initialize_options.
* Create basic tests to verify the functionality of msgmerge, specifically the merging of messages and their integration with a compendium. * Remove the definition of sort-output and sort-by-file, and add an additional check for input-files.
…m handling logic * Implement `update` to update the source file instead of writing to the current output file * Implement `backup` to save a backup of the source file before making any updates * Implement `c_overwrite` to use a new mode of handling the compendium, where translations from the compendium overwrite messages in the output file
* Implement a test for `msgmerge` that validates the new mode where compendium entries overwrite messages in the output PO file. * Include the `no_compendium_comment` option to ensure comments about translations sourced from the compendium are not included. * Utilize the `no-location` option to exclude location comments from the output.
* Implemented a helper function `_get_expected` to standardize the expected PO file structure. * Renamed the option `c-overwrite` to `compendium-overwrite`
* Mark the catalog as fuzzy after msgcat and msgmerge if there is at least one fuzzy message * Remove add-location as it's unnecessary
Hi guys! I see you marked pr but still haven't left any comments. Will it be reviewed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Some initial comments within.
|
||
def finalize_options(self): | ||
if not self.input_files or len(self.input_files) != 2: | ||
raise OptionError('must be two po files') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the order of the files has some semantics to it? definition file, reference file..?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the first one is a file with obsolete translations, the second one is new actual .pot file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be useful information here in the error message too.
tests/messages/test_frontend.py
Outdated
@@ -715,6 +715,431 @@ def test_supports_width(self): | |||
assert expected_content == actual_content | |||
|
|||
|
|||
class ConcatanationCatalogTestCase(unittest.TestCase): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new test cases could live in new files, I think.
And if you feel like it, they could be Pytest style instead of Unittest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is a new file really needed here? The file is test_frontend.py and all other tests for commands are there and it's logical that they will be there too, no?
* Update _prepare function in ConcatenateCatalog to check conflicting messages and to not parse po-files twice * Add _conflicts field in Catalog to mark conflicts * Update tests
* Delete unused options * Fix multiline options comments * Replace backup logic in MergeCatalog * Rename to ConcatenateCatalog
Made support for conflicting messages from different po-files during concatenation. If one message has different translations in different files, then the corresponding strings marked with a comment about conflict |
* Includes .rst file with detailed use cases and practical examples for pybabel's concat and merge utilities, outlining common scenarios, options, and best practices for managing PO files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another round of comments :)
@@ -642,6 +645,37 @@ def _format_comment(comment, prefix=''): | |||
for line in comment_wrapper.wrap(comment): | |||
yield f"#{prefix} {line.strip()}\n" | |||
|
|||
def _format_conflict_comment(file, project, version, prefix=''): | |||
comment = f"#-#-#-#-# {file} ({project} {version}) #-#-#-#-#" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this standard notation, or are we introducing a Babel-specific comment extension? If the latter, I'd rather not...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the notation used in gnu gettext
* Rename file_name to filename * Adding fuzzy flag to message parameterized in 'add_conflict' * Replace usage scenarious to cmdline.rst * Rename to ConcatenateCatalog
* Add frozen_time fixture to use freeze_time in every test
Implementation of some features for msgcat and msgmerge to work with a compendium in PyBabel
pybabel concat
pybabel merge