Node sockets could already be declared using:
```cpp
add_input<decl::<SOCKET TYPE>>("NAME")
```
They can now additionally be declared with:
```cpp
add_input(socket_type, "NAME")
```
This commit adds the later form to the message extraction regex. Since
they are mutually exclusive, they are now in a non-capturing group
with an | operator.
Reported by Ye Gui in #43295.
This extracts the names and descriptions for displays, views, and
colorspaces. They are all used in the different parts of the UI.
The views' descriptions are used for the displays'.
The extraction uses the built-in PyOpenColorIO module. This ensures
only data that is actually used is extracted (not ignored in the
config).
Commit 9ce0a2d1d5 added the ability to specify translation contexts to
node UI panels, but it failed to update the regex that extracts them.
This commit solves that by adding the proper `add_panel` function to
the extraction regex.
Reported by Satoshi Yamasaki in #43295.
Job names displayed in the status bar were not extracted or
translated. This commit adds a regex to the bl_i18n_utils settings to
detect `WM_jobs_get()`, and the `RPT_` translation macro to translate
the message in the UI.
About 30 new messages are translated.
Reported by Ye Gui in #43295.
Geometry Nodes' Add > Input > Import menu includes file format items
such as "Standford PLY (.ply)", "STL (.stl)", "Text (.txt)". The
latter needs to be translated because "Text" is a generic format.
These items are declared using a custom function
`node_add_menu.add_node_type`, with a `label` argument. This commit
adds the `label` argument to the function arguments that can be
extracted from specific node declaration functions, and specifies the
argument position for each:
"add_node_type", "add_node_type_with_outputs", "add_simulation_zone",
"add_repeat_zone", "add_foreach_geometry_element_zone",
"add_closure_zone".
There is currently no facility to specify a translation context but it
could be easily added if the need arises.
Most of these functions do not actually declare new, unique messages,
but it could happen in the future. In addition, two messages were
extracted using manual `iface_()` calls, which are no longer needed
after this change.
Reported by Ye Gui in #43295.
Edit the language list to make it simpler to scan.
- Display languages in a form "Language (Variant)", such as
"English (US)" instead of "American English" and
"Portuguese (Brazil)" instead of "Brazilian Portuguese".
This allows alphabetical sorting by language first.
This does not apply to endonyms (languages in their own language).
- Use a dash instead of parentheses to separate the endonyms.
- Deduplicate languages (Automatic, American English, British
English), which all are in English and don't appear in another
language.
- Remove language categories as headers. They are replaced with
percentages in the language tooltips. The percentages are
generated in utils_languages_menu.py and stored in
locale/languages.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/140087
Remove long-deprecated constraints that will likely never be
implemented in this form.
- Rigid Body Joint Constraint was removed in 2.80, but some references
remained in the code. Versioning code was written that tried to
remove them on load, but since constraint initialization code sets
the type to CONSTRAINT_TYPE_NULL before versioning gets a chance,
the versioning code ended up never running. This has all been
removed.
- Python/Script Constraint never worked since 2.50 and showed an error
message in the UI panel.
These constraints now load as 'null' constraint, as seems to be
(looking at the code) the way that Blender currently deals with
removed constraint types. These still show up in the outliner and
python API, but have no UI panel. Removing such constraints completely
will be left for another time, as it is beyond the scope of removing
these two specific constraint types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136672
Operators keep being a pain... This time, the fact that unregistered
operators are not removed from `bpyt.type.Operator` subclasses list
breaks workflow to generate translations info for a specific add-on
(since it relies on differences between UI messages extracted when this
add-on is enabled, and when it is disabled).
Suppress unused warnings using the "vulture" utility.
- Include public definitions in the modules `__all__`.
- Mark arguments & variables as unused with a "_" prefix.
BaseException was used as a catch-all in situations where it
didn't make sense and where "Exception" is more appropriate
based on Python's documentation & error checking tools,
`pylint` warns `broad-exception-caught` for e.g.
BaseException includes SystemExit, KeyboardInterrupt & GeneratorExit,
so unless the intention is to catch calls to `sys.exit(..)`,
breaking a out of a loop using Ctrl-C or generator-exit,
then it shouldn't be used.
Even then, it's preferable to catch those exceptions explicitly.
Recent fix 21b820cd33 in BPY/RNA code broke introspection code of RNA
data in i18n message extraction code.
Luckily, it actually fixes things, and allows to remove some of the ugly
hacks we had in this code, especially regarding Operators handling.
- Paths of C++-parsed files were not properly 'unixified' on Windows.
This was bad both for changes noisyness in PO files, and broke on
the un-escaping of `\n` and `\t` sequences.
- The `ProcessPoolExecutor` starts sub-processes differently on Linux
than on Windows or OSX. While Linux's `fork` keeps the same
environment (i.e. all Blender stuff remains available in workers
subprocesses), the 'spawn' used on Windows (and reportedly OSX) starts
a new bare python interpreter. This means that code executed by these
needs to be Blender-agnostic to be portable.
The only thing that is currently known broken on non-Linux platforms is
the RTL processing of some languages like Arabic or Hebrew.
The BLT_I18N_MSGID_MULTI_CTXT() macro allows extracting a single
message into up to 16 different contexts. The regex to do that was
slightly wrong because it did not account for the macro potentially
ending with a ",".
The contexts for "New" were also sorted.
Pull Request: https://projects.blender.org/blender/blender/pulls/123793
The new extension system introduces tags, similar to categories from
legacy add-ons, and permissions. A hardcoded list is supported for
each, available in the docs:
- https://docs.blender.org/manual/en/dev/advanced/extensions/tags.html
- https://developer.blender.org/docs/features/extensions/schema/
This change allows extraction of these new metadata to the translation
files.
In order to disambiguate the new messages, tags use the new "Script"
translation context. Permissions are lower case, so there is a low
risk of collision, and they use the default context.
While the tags are defined per-platform, with extensions.blender.org
being the only one available currently, they are extracted as a single
list.
Pull Request: https://projects.blender.org/blender/blender/pulls/123150
- The "location" and "warning" fields in bl_info are no longer exposed
in the interface, so there is no need to extract them any more.
- Some add-ons do not define a description (Copy Global Transform for
example), so they should be skipped.
- Some third-party legacy add-ons do not use the 'support' field, and
that can cause an error in extraction. Since this won't happen
for built-in add-ons, checking that an add-on is built-in is enough.
Pull Request: https://projects.blender.org/blender/blender/pulls/122970
The translation extraction goes through each keyconfig preset file and
activates it in order to extract its messages. This change makes it
restore the original config, otherwise it would end up switching to
Industry Compatible.
Pull Request: https://projects.blender.org/blender/blender/pulls/122789
Using `bpy.types.OperatorProperties.__subclasses__()` has become utterly
unreliable now, to the point that it keeps references to freed (aka
unregistered) operators now, leading to crash when accessing them.
This commit refactors quite seriously the `dump_rna_messages` code, by
first listing all 'valid' classes, and then processing them all at once
in a flat iteration.
RNA classes are still generated from class hierarchy rooted on the
'virtual' `rna_struct` one, except for operators. These are now
generated by introspecting `bpy.ops` instead.
