Since add-on info was made translatable in D15747, user-installed
add-ons could also get their info extracted. This led to having
different messages depending on the environment of the Blender doing
the I18n messages update.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
Event Timeline
| release/scripts/modules/bl_i18n_utils/bl_extract_messages.py | ||
|---|---|---|
| 982 | Would add a comment here to explain a bit more, had to think a bit to understand why you did not just use thew OFFICIAL check for this one too. Something like: # Ignore add-on if it's not a system one (i.e it's user-installed). # NOTE: We do want to translate official categories, even if they have no official add-ons, hence the different test than below. | |
| release/scripts/modules/bl_i18n_utils/bl_extract_messages.py | ||
|---|---|---|
| 982 | I hadn’t considered that actually, I didn’t think there could be categories without add-ons! To me the issue was if an add-on developer decided to mark its support level as OFFICIAL even though it’s not issued by the BF. If the person doing the i18n update installs this add-on, we get irrelevant info. And I noticed the issue with categories below because in the same .po update there is a “MakeHuman” category which, again, doesn’t look really official. I’ll improve the comment. | |
| release/scripts/modules/bl_i18n_utils/bl_extract_messages.py | ||
|---|---|---|
| 982 | Wait a second, I got mixed up between categories and bl_info. The categories without add-ons are All and User, handled in the elif tip: block below. So maybe the comment you suggested was meant for the next block? Anyway, it was murky, I reworked the logic a bit. | |
Comment Actions
Ok I understand better too. Almost good to go now :)
| release/scripts/modules/bl_i18n_utils/bl_extract_messages.py | ||
|---|---|---|
| 982–983 | Would rephrase this that way: # Only process official add-ons, i.e. those marked as 'OFFICIAL' and # existing in the system add-ons directory (not user-installed ones). | |
| 988–989 | This can be removed now then | |
Comment Actions
Eeeeh looks like this does not apply anymore on current master, can you please update it? thanks.
Comment Actions
Sure thing!
There was indeed a conflict on rebase, but it was in source/tools, a dir I never actually touched. Is this a submodule thing? I thought Phabricator’s patch-based workflow would prevent this sort of conflicts.
Anyway, I hope it works now :)