blender
/
blender
129
398
Fork 572
Code Issues 6.2k Pull Requests 747 Projects 19 Wiki Activity

Translated Interface when enable Tooltips #76101

New Issue
Closed
opened 2020-04-25 18:24:42 +02:00 by Grigoriy Titaev · 31 comments
Grigoriy Titaev commented 2020-04-25 18:24:42 +02:00
Copy Link

Operating system: Windows
Blender Version: 2.83.15

Short description of error
If you enable translation "Tooltips" then some interface elements are translated.
They must be translated if you enable translation "Interface", not "Tooltips".
Blender translation.png

Operating system: Windows Blender Version: 2.83.15 **Short description of error** If you enable translation "Tooltips" then some interface elements are translated. They must be translated if you enable translation "Interface", not "Tooltips". ![Blender translation.png](https://archive.blender.org/developer/F8494626/Blender_translation.png)
Grigoriy Titaev commented 2020-04-25 18:24:42 +02:00
Author
Copy Link

Added subscriber: @gtitaev

Added subscriber: @gtitaev
blender-admin commented 2020-04-25 18:24:42 +02:00
Copy Link

#76228 was marked as duplicate of this issue

#76228 was marked as duplicate of this issue
Ankit Meel commented 2020-04-25 19:03:57 +02:00
Member
Copy Link

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
Ankit Meel commented 2020-04-25 19:10:51 +02:00
Member
Copy Link

Added subscriber: @ankitm

Added subscriber: @ankitm
Ankit Meel commented 2020-04-29 15:22:45 +02:00
Member
Copy Link

Added subscriber: @pablovazquez

Added subscriber: @pablovazquez
Brecht Van Lommel commented 2020-05-01 19:17:31 +02:00
Owner
Copy Link

Added subscriber: @brecht

Added subscriber: @brecht
Brecht Van Lommel commented 2020-05-01 19:17:31 +02:00
Owner
Copy Link

This is a matter of going through the code and changing TIP_ to IFACE_ in a bunch of places.

This is a matter of going through the code and changing `TIP_` to `IFACE_` in a bunch of places.
Hans Goudey commented 2020-07-15 21:27:30 +02:00
Member
Copy Link

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Hans Goudey commented 2020-07-15 21:27:30 +02:00
Member
Copy Link

@brecht In general the only string that should use TIP_ are the tooltips that show up on mouse hover, right? Just want to be sure, then I can fix this stuff when I run into it.

@brecht In general the only string that should use `TIP_` are the tooltips that show up on mouse hover, right? Just want to be sure, then I can fix this stuff when I run into it.
Brecht Van Lommel commented 2020-07-15 21:32:15 +02:00
Owner
Copy Link

@HooglyBoogly indeed, that's how I would expect the option to work. The idea being that you can enable just tooltips and have interface completely in English, except when hovering over buttons.

@HooglyBoogly indeed, that's how I would expect the option to work. The idea being that you can enable just tooltips and have interface completely in English, except when hovering over buttons.
Hans Goudey commented 2020-07-15 21:43:52 +02:00
Member
Copy Link

Do you think it's fine to commit those fixes or would a patch be necessary?

Do you think it's fine to commit those fixes or would a patch be necessary?
Brecht Van Lommel commented 2020-07-16 12:36:43 +02:00
Owner
Copy Link

You can commit those fixes directly.

You can commit those fixes directly.
Hans Goudey commented 2020-07-16 16:52:19 +02:00
Member
Copy Link

Added subscriber: @mont29

Added subscriber: @mont29
Hans Goudey commented 2020-07-16 16:52:19 +02:00
Member
Copy Link

While looking into this I actually found this commit from @mont29: 23df1a774b

I realized I was mostly reversing those changes so it's probably best to talk about it first.
There seems to be lots of confusion about what the "Interface" property in preferences means.
I get the argument that these strings are sort of like tooltips, but it doesn't seem clear to me that
that setting is meant to change reports and status text as well. That's why we get bug reports about it.

Admittedly I don't have the experience of using Blender in a language besides my native language, but
I would suggest a couple options:

  1. Add a third option for for reports and messages
  2. Clarify the meaning / name of the "Interface" property
  3. Only translate these areas with interface translation turned on.
While looking into this I actually found this commit from @mont29: 23df1a774b I realized I was mostly reversing those changes so it's probably best to talk about it first. There seems to be lots of confusion about what the "Interface" property in preferences means. I get the argument that these strings are sort of like tooltips, but it doesn't seem clear to me that that setting is meant to change reports and status text as well. That's why we get bug reports about it. Admittedly I don't have the experience of using Blender in a language besides my native language, but I would suggest a couple options: 1. Add a third option for for reports and messages 2. Clarify the meaning / name of the "Interface" property 3. Only translate these areas with interface translation turned on.
Julian Eisel commented 2020-09-05 16:40:43 +02:00
Member
Copy Link

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Julian Eisel commented 2020-09-05 16:40:43 +02:00
Member
Copy Link

From what Hans linked and explained, there is a design question. And what's reported here is an intentional change. So changing this into a known issue, it's not a bug.

From what Hans linked and explained, there is a design question. And what's reported here is an intentional change. So changing this into a known issue, it's not a bug.
Bastien Montagne added this to the User Interface project 2023-02-09 15:34:10 +01:00
Philipp Oeser removed the
Interest
User Interface
 label 2023-02-10 09:24:31 +01:00
Grigoriy Titaev commented 2023-04-04 09:24:47 +02:00
Author
Copy Link

The way it works now sometimes gets in the way. Sometimes you have to disable and enable tooltips.

  1. Add a third option for for reports and messages

This seems to be a more flexible solution:

  • "Tooltips" TIP_ only for tooltips that show up on mouse hover.
  • And add new option "Interface Tips" ITIP_ for some interface messages.
The way it works now sometimes gets in the way. Sometimes you have to disable and enable tooltips. > 1. Add a third option for for reports and messages This seems to be a more flexible solution: - "Tooltips" `TIP_` only for tooltips that show up on mouse hover. - And add new option "Interface Tips" `ITIP_` for some interface messages.
Harley Acheson commented 2023-08-30 18:51:24 +02:00
Member
Copy Link

My opinion is that we should make these changes, replacing TIP_ to IFACE_ for usages that are not for popup tooltips.

I think Brecht's comment explains the intent with these perfectly: "you can enable just tooltips and have interface completely in English, except when hovering over buttons". If "Tooltips" is enabled but not "Interface" the program should be indistinguishable from running it in English, expect when you hover over an item to see a tooltip. Every other part, including logs, warnings, info, and even console messages should be in English. This is meant for bilingual users who want to run the program as they see it in tutorials but still need to confirm some parts with the tooltips in their native language.

Much more controversial, is that once this is done I think we should consider taking this a step further. Allow the program to display the interface in any language and the tooltips in any language. Therefore the intent for this to aid bilingual users extends to everyone, not just being bilingual with English.

The use case for this might seem small for those of us who speak English, but the world has a very large amount of people who know more than one language that does not include English. For these users they are likely to watch tutorials in the more popular of their languages but might need tooltips for their native one.

My opinion is that we **should** make these changes, replacing `TIP_` to `IFACE_` for usages that are not for popup tooltips. I think Brecht's comment explains the intent with these perfectly: "you can enable just tooltips and have interface completely in English, except when hovering over buttons". If "Tooltips" is enabled but not "Interface" the program should be indistinguishable from running it in English, expect when you hover over an item to see a tooltip. Every other part, including logs, warnings, info, and even console messages should be in English. This is meant for bilingual users who want to run the program as they see it in tutorials but still need to confirm some parts with the tooltips in their native language. Much more controversial, is that once this is done I think we should _consider_ taking this a step further. Allow the program to display the interface in any language and the tooltips in any language. Therefore the intent for this to aid bilingual users extends to everyone, not just being bilingual with English. The use case for this might seem small for those of us who speak English, but the world has a very _large amount of people who know more than one language that does not include English_. For these users they are likely to watch tutorials in the more popular of their languages but might need tooltips for their native one.
👍 3
Bastien Montagne commented 2023-08-31 09:59:59 +02:00
Owner
Copy Link

I fully disagree here.

The points of these options is not to be pretty or neat, it's to help as much as possible users who are not at ease enough in English. As such, the current distinction between UI and Tooltip options has been based on how complex and informative the message is, vs. how important it is to keep it in English to be able to follow documentation referencing the default UI:

  • Tooltips, log/error messages, and other long(ish) info are typically more complicated English, and the vast majority of these will not appear by default in the UI. Further more, their reference in documentation will also be fairly rare.
  • Labels are very short, usually simpler English, and are omnipresent in default UI, and in documentation.

I'd rather improve current naming and descriptions of the options, than change their current behavior. Adding a third 'interface tip' would be more acceptable, but right now I don't really see the benefits of it...

@gtitaev I would like to know what is exactly your issue with the current design? Why do you have to sometimes enable/disable tooltips option?

As for mixing two different, non-English languages in the UI, the change would be trivial technically, but would add more clutter in the settings. And I highly doubt it would add any actual benefit to the users, even bi-lingual ones that do not know any English. At least given the current state of most of our translations.

  • Typically users will be (way) more at ease in one language anyway, in which case they would just choose their same 'best' language for both UI and tooltips.
  • Only potentially useful case where users would want to enable two different languages I can think of would be if their primary language was very poorly translated - but in such case, that would lead to having three languages in the end, English, one good-enough translation that would not be the ideal choice, and one poor translation in their primary language... Does not sound like a nice situation to me.
  • On top of that, getting proper terminology consistency within a single translation is already... far from trivial. And terminology choices vary widely between translations. Another great source of confusion.
I fully disagree here. The points of these options is not to be pretty or neat, it's to help as much as possible users who are not at ease enough in English. As such, the current distinction between UI and Tooltip options has been based on how complex and informative the message is, vs. how important it is to keep it in English to be able to follow documentation referencing the default UI: * Tooltips, log/error messages, and other long(ish) info are typically more complicated English, and the vast majority of these will not appear by default in the UI. Further more, their reference in documentation will also be fairly rare. * Labels are very short, usually simpler English, and are omnipresent in default UI, and in documentation. I'd rather improve current naming and descriptions of the options, than change their current behavior. Adding a third 'interface tip' would be more acceptable, but right now I don't really see the benefits of it... @gtitaev I would like to know what is exactly your issue with the current design? Why do you have to sometimes enable/disable tooltips option? As for mixing two different, non-English languages in the UI, the change would be trivial technically, but would add more clutter in the settings. And I highly doubt it would add any actual benefit to the users, even bi-lingual ones that do not know any English. At least given the current state of most of our translations. * Typically users will be (way) more at ease in one language anyway, in which case they would just choose their same 'best' language for both UI and tooltips. * Only potentially useful case where users would want to enable two different languages I can think of would be if their primary language was very poorly translated - but in such case, that would lead to having three languages in the end, English, one good-enough translation that would not be the ideal choice, and one poor translation in their primary language... Does not sound like a nice situation to me. * On top of that, getting proper terminology consistency within a single translation is already... far from trivial. And terminology choices vary widely between translations. Another great source of confusion.
Julian Eisel commented 2023-08-31 11:48:49 +02:00
Member
Copy Link

Main problem is that the Preferences clearly provide an option labeled "Tooltips" which affects way more than tooltips. This is misleading and keeps causing confusion. Not just for users, how many times did we have to correct the code and explain this to developers?

I think there is use in keeping explanation texts (tooltips) translated to make them more understandable, while keeping things like warning, error or even info messages in English. This way you can search for the message online and find more help this way. So to me it seems like this should be a separate option (and we make the "Tooltips" option only actually apply to tooltips!).

Main problem is that the Preferences clearly provide an option labeled "Tooltips" which affects way more than tooltips. This is misleading and keeps causing confusion. Not just for users, how many times did we have to correct the code and explain this to developers? I think there is use in keeping explanation texts (tooltips) translated to make them more understandable, while keeping things like warning, error or even info messages in English. This way you can search for the message online and find more help this way. So to me it seems like this should be a separate option (and we make the "Tooltips" option only actually apply to tooltips!).
👍 3
Grigoriy Titaev commented 2023-09-06 19:31:22 +02:00
Author
Copy Link

@gtitaev I would like to know what is exactly your issue with the current design?

Inconsistency, bilingualism of the interface.
The same thing in the status bar and interface in different languages, it sometimes causes confusion.
It would like the terminology, parameters, tools, operations, ... to be in the same language everywhere.
Translation - Status Bar.png

Why do you have to sometimes enable/disable tooltips option?

There were a couple of places in the interface where what was not needed was translated, like this: #106422.
Now I don't remember where it was, maybe it was fixed in new versions.

  • Typically users will be (way) more at ease in one language anyway, in which case they would just choose their same 'best' language for both UI and tooltips.

I prefer the entire interface in English (including all messages), and only tooltips in my language.
It may be useful for someone to translate messages in the interface (as it is done now), but I would prefer to be able to disable this.

Ideally, to meet the needs of all users, there should be three parameters in the settings:

  1. Translate only the tooltips.
  2. Translate in the interface: messages, other hints, ...
  3. Translate the entire interface.
> @gtitaev I would like to know what is exactly your issue with the current design? Inconsistency, bilingualism of the interface. The same thing in the status bar and interface in different languages, it sometimes causes confusion. It would like the terminology, parameters, tools, operations, ... to be in the same language everywhere. ![Translation - Status Bar.png](/attachments/2b491666-086e-4380-84ee-10acff021ce4) > Why do you have to sometimes enable/disable tooltips option? There were a couple of places in the interface where what was not needed was translated, like this: #106422. Now I don't remember where it was, maybe it was fixed in new versions. > * Typically users will be (way) more at ease in one language anyway, in which case they would just choose their same 'best' language for both UI and tooltips. I prefer the entire interface in English (including all messages), and only tooltips in my language. It may be useful for someone to translate messages in the interface (as it is done now), but I would prefer to be able to disable this. Ideally, to meet the needs of all users, there should be three parameters in the settings: 1. Translate only the tooltips. 2. Translate in the interface: messages, other hints, ... 3. Translate the entire interface.
Translation - Status Bar.png
268 KiB
Brecht Van Lommel commented 2024-01-04 01:51:17 +01:00
Owner
Copy Link

I think there is use in keeping explanation texts (tooltips) translated to make them more understandable, while keeping things like warning, error or even info messages in English. This way you can search for the message online and find more help this way. So to me it seems like this should be a separate option (and we make the "Tooltips" option only actually apply to tooltips!).

I think this suggestion by @JulianEisel was good.

@mont29 in your previous comment you said you didn't see the benefit, but it seems others here do and there are no significant downsides that I can see. Do you have any objection to that change, can someone just go ahead and implement it?

> I think there is use in keeping explanation texts (tooltips) translated to make them more understandable, while keeping things like warning, error or even info messages in English. This way you can search for the message online and find more help this way. So to me it seems like this should be a separate option (and we make the "Tooltips" option only actually apply to tooltips!). I think this suggestion by @JulianEisel was good. @mont29 in your previous comment you said you didn't see the benefit, but it seems others here do and there are no significant downsides that I can see. Do you have any objection to that change, can someone just go ahead and implement it?
👍 1
Bastien Montagne commented 2024-01-04 10:08:42 +01:00
Owner
Copy Link

Am not convinced (mainly because this adds yet another set of macros and option for i18n), but not really opposed to it either, if other people think this is helpful.

For the naming base of this new set, we could use report (and RPT for short, for the macros e.g.)?

I can do the initial 'low-level' change, but could use some help to track down all cases in the UI messages that needs to be modified. And i18n doc will also need to be updated. @pioverfour maybe would be interested in helping (or fully taking over to implement this change, think it's fairly straightforward)?

Am not convinced (mainly because this adds yet another set of macros and option for i18n), but not really opposed to it either, if other people think this is helpful. For the naming base of this new set, we could use `report` (and `RPT` for short, for the macros e.g.)? I can do the initial 'low-level' change, but could use some help to track down all cases in the UI messages that needs to be modified. And i18n doc will also need to be updated. @pioverfour maybe would be interested in helping (or fully taking over to implement this change, think it's fairly straightforward)?
Damien Picard commented 2024-01-04 10:31:54 +01:00
Member
Copy Link

@mont29 Hi, I could definitely help with it. I also think it’s straightforward but I’ll need to try it to know if it’s in my reach. I’ll let you know soon.

FWIW I agree that the current state is confusing both for developers and users, and a new category would help. report sounds good to me at first glance, but it might need to be changed when we go over the various uses, if it turns out not to fit. At first I was thinking of "Extra info" / info myself, but not too sure about it.

I also agree with Harley’s assessment that for many folks, it would be useful to set a different language for each category. But that’s another step.

@mont29 Hi, I could definitely help with it. I also think it’s straightforward but I’ll need to try it to know if it’s in my reach. I’ll let you know soon. FWIW I agree that the current state is confusing both for developers and users, and a new category would help. `report` sounds good to me at first glance, but it might need to be changed when we go over the various uses, if it turns out not to fit. At first I was thinking of "Extra info" / `info` myself, but not too sure about it. I also agree with Harley’s assessment that for many folks, it would be useful to set a different language for each category. But that’s another step.
👍 1
Bastien Montagne commented 2024-01-04 11:38:01 +01:00
Owner
Copy Link

Regarding multi-languages selection, I would like to get answers to my reasoning about why I find it a bad idea then. :)

  • Typically users will be (way) more at ease in one language anyway, in which case they would just choose their same 'best' language for both UI and tooltips.
  • Only potentially useful case where users would want to enable two different languages I can think of would be if their primary language was very poorly translated - but in such case, that would lead to having three languages in the end, English, one good-enough translation that would not be the ideal choice, and one poor translation in their primary language... Does not sound like a nice situation to me.
  • On top of that, getting proper terminology consistency within a single translation is already... far from trivial. And terminology choices vary widely between translations. Another great source of confusion.
Regarding multi-languages selection, I would like to get answers to my reasoning about why I find it a bad idea then. :) > * Typically users will be (way) more at ease in one language anyway, in which case they would just choose their same 'best' language for both UI and tooltips. > * Only potentially useful case where users would want to enable two different languages I can think of would be if their primary language was very poorly translated - but in such case, that would lead to having three languages in the end, English, one good-enough translation that would not be the ideal choice, and one poor translation in their primary language... Does not sound like a nice situation to me. > * On top of that, getting proper terminology consistency within a single translation is already... far from trivial. And terminology choices vary widely between translations. Another great source of confusion.
Damien Picard commented 2024-01-04 12:24:55 +01:00
Member
Copy Link

I can’t say it better than Harley, that while English seems to have the majority of documentation compared to other languages, you can find tutorials and information in many others. It’s easy to imagine someone speaking, say Catalan and Spanish, or Turkish and German, or Nepali and Hindi, or any combination of languages where a specific tutorial exists only in one language, wanting to have tooltips in one and interface in the other.

I don’t think we should limit the choice based on the current state of translations, especially with many languages making good progress since the new Weblate interface. Even if one or both risk being only partially translated, it’s better than nothing for someone speaking no English, IMO.

As to the confusion from terminology, I’m not knowledgeable enough about linguistics to know how much of a problem it is. But here too I think it’s better than nothing, and a separate issue.

I can’t say it better than Harley, that while English seems to have the majority of documentation compared to other languages, you can find tutorials and information in many others. It’s easy to imagine someone speaking, say Catalan and Spanish, or Turkish and German, or Nepali and Hindi, or any combination of languages where a specific tutorial exists only in one language, wanting to have tooltips in one and interface in the other. I don’t think we should limit the choice based on the current state of translations, especially with many languages making good progress since the new Weblate interface. Even if one or both risk being only partially translated, it’s better than nothing for someone speaking no English, IMO. As to the confusion from terminology, I’m not knowledgeable enough about linguistics to know how much of a problem it is. But here too I think it’s better than nothing, and a separate issue.
Brecht Van Lommel commented 2024-01-04 12:25:04 +01:00
Owner
Copy Link

For multiple languages, I guess that should not be about picking which parts of the UI use which language, but rather about choosing a fallback language other than English for everything.

And those fallback languages probably should only be ones that are > 99% translated. So for example you could have 54% translated Portuguese fall back to Spanish.

For multiple languages, I guess that should not be about picking which parts of the UI use which language, but rather about choosing a fallback language other than English for everything. And those fallback languages probably should only be ones that are > 99% translated. So for example you could have 54% translated Portuguese fall back to Spanish.
👍 1
Bastien Montagne commented 2024-01-04 14:47:24 +01:00
Owner
Copy Link

Sounds doable, since we already sort languages by completeness for the menu, for the second backup we could just show these in the Complete section (although current threshold is 95%).

But that means that the list of backup will get languages added and removed (almost) every week on translations updates... Not an issue for releases, but could be annoying for users of the nightly builds?

Also, how should 'disabled translations' categories be handled then (e.g. if user disable the translation of tooltips, do these show in English, or in the fallback language)?

Sounds doable, since we already sort languages by completeness for the menu, for the second backup we could just show these in the `Complete` section (although current threshold is 95%). But that means that the list of backup will get languages added and removed (almost) every week on translations updates... Not an issue for releases, but could be annoying for users of the nightly builds? Also, how should 'disabled translations' categories be handled then (e.g. if user disable the translation of tooltips, do these show in English, or in the fallback language)?
Brecht Van Lommel commented 2024-01-04 15:51:25 +01:00
Owner
Copy Link

I don't know what exactly the right threshold is. I would guess > 95 is going to be pretty stable in practice.

I think disabled translations would show in the fallback language, if this is for users who don't understand English that well. Having 3 languages used seems a bit much.

I don't know what exactly the right threshold is. I would guess > 95 is going to be pretty stable in practice. I think disabled translations would show in the fallback language, if this is for users who don't understand English that well. Having 3 languages used seems a bit much.
👍 2
Damien Picard commented 2024-01-04 22:54:33 +01:00
Member
Copy Link

Creating !116804 was indeed a rather straightforward copy-paste affair, but going over most or all uses of each macro should take much longer!

Messages that are not obvious are those that appear as labels in panels, but contain extra information currently translated with TIP_(). One example is the light cache status in EEVEE’s Indirect Lighting panel:
image

Or various messages displayed in modifiers:
image

I’d like to bring those back to the regular interface translation, but they could also be switched to RPT_().

Creating !116804 was indeed a rather straightforward copy-paste affair, but going over most or all uses of each macro should take much longer! Messages that are not obvious are those that appear as labels in panels, but contain extra information currently translated with `TIP_()`. One example is the light cache status in EEVEE’s Indirect Lighting panel: ![image](/attachments/fbb8d800-0447-419d-b045-e7c62bc0d492) Or various messages displayed in modifiers: ![image](/attachments/5876dbaf-1760-47cd-a6a1-1425ab6b9639) I’d like to bring those back to the regular interface translation, but they could also be switched to `RPT_()`.
image.png
18 KiB
image.png
28 KiB
👍 2
Bastien Montagne commented 2024-01-05 00:11:08 +01:00
Owner
Copy Link

Creating !116804 was indeed a rather straightforward copy-paste affair, but going over most or all uses of each macro should take much longer!

Nice! 👍

Messages that are not obvious are those that appear as labels in panels, but contain extra information currently translated with TIP_(). One example is the light cache status in EEVEE’s Indirect Lighting panel:
image

Or various messages displayed in modifiers:
image

I’d like to bring those back to the regular interface translation, but they could also be switched to RPT_().

I would also expect these to be moved to the new report category indeed!

> Creating !116804 was indeed a rather straightforward copy-paste affair, but going over most or all uses of each macro should take much longer! Nice! 👍 > Messages that are not obvious are those that appear as labels in panels, but contain extra information currently translated with `TIP_()`. One example is the light cache status in EEVEE’s Indirect Lighting panel: > ![image](/attachments/fbb8d800-0447-419d-b045-e7c62bc0d492) > > Or various messages displayed in modifiers: > ![image](/attachments/5876dbaf-1760-47cd-a6a1-1425ab6b9639) > > I’d like to bring those back to the regular interface translation, but they could also be switched to `RPT_()`. I would also expect these to be moved to the new report category indeed!
👍 1
Blender Bot added
Status
Resolved
 and removed
Status
Confirmed
 labels 2024-01-12 13:37:45 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
brush-assets-project
blender-v4.1-release
blender-v3.3-release
blender-v3.6-release
universal-scene-description
blender-v3.6-temp_wmoss_animrig_public
temp-sculpt-dyntopo
gpencil-next
anim/animation-id-113594
blender-v4.0-release
blender-projects-basics
bridge-curves
sculpt-blender
asset-browser-frontend-split
asset-shelf
tmp-usd-python-mtl
tmp-usd-3.6
blender-v3.5-release
blender-v2.93-release
realtime-clock
sculpt-dev
bevelv2
xr-dev
v4.1.1
v3.6.11
v3.3.18
v4.1.0
v3.3.17
v3.6.10
v3.6.9
v3.3.16
v3.6.8
v3.6.7
v3.3.14
v4.0.2
v4.0.1
v4.0.0
v3.6.5
v3.3.12
v3.6.4
v3.6.3
v3.3.11
v3.6.2
v3.3.10
v3.6.1
v3.3.9
v3.6.0
v3.3.8
v3.3.7
v2.93.18
v3.5.1
v3.3.6
v2.93.17
v3.5.0
v2.93.16
v3.3.5
v3.3.4
v2.93.15
v2.93.14
v3.3.3
v2.93.13
v2.93.12
v3.4.1
v3.3.2
v3.4.0
v3.3.1
v2.93.11
v3.3.0
v3.2.2
v2.93.10
v3.2.1
v3.2.0
v2.83.20
v2.93.9
v3.1.2
v3.1.1
v3.1.0
v2.83.19
v2.93.8
v3.0.1
v2.93.7
v3.0.0
v2.93.6
v2.93.5
v2.83.18
v2.93.4
v2.93.3
v2.83.17
v2.93.2
v2.93.1
v2.83.16
v2.93.0
v2.83.15
v2.83.14
v2.83.13
v2.92.0
v2.83.12
v2.91.2
v2.83.10
v2.91.0
v2.83.9
v2.83.8
v2.83.7
v2.90.1
v2.83.6.1
v2.83.6
v2.90.0
v2.83.5
v2.83.4
v2.83.3
v2.83.2
v2.83.1
v2.83
v2.82a
v2.82
v2.81a
v2.81
v2.80
v2.80-rc3
v2.80-rc2
v2.80-rc1
v2.79b
v2.79a
v2.79
v2.79-rc2
v2.79-rc1
v2.78c
v2.78b
v2.78a
v2.78
v2.78-rc2
v2.78-rc1
v2.77a
v2.77
v2.77-rc2
v2.77-rc1
v2.76b
v2.76a
v2.76
v2.76-rc3
v2.76-rc2
v2.76-rc1
v2.75a
v2.75
v2.75-rc2
v2.75-rc1
v2.74
v2.74-rc4
v2.74-rc3
v2.74-rc2
v2.74-rc1
v2.73a
v2.73
v2.73-rc1
v2.72b
2.72b
v2.72a
v2.72
v2.72-rc1
v2.71
v2.71-rc2
v2.71-rc1
v2.70a
v2.70
v2.70-rc2
v2.70-rc
v2.69
v2.68a
v2.68
v2.67b
v2.67a
v2.67
v2.66a
v2.66
v2.65a
v2.65
v2.64a
v2.64
v2.63a
v2.63
v2.61
v2.60a
v2.60
v2.59
v2.58a
v2.58
v2.57b
v2.57a
v2.57
v2.56a
v2.56
v2.55
v2.54
v2.53
v2.52
v2.51
v2.50
v2.49b
v2.49a
v2.49
v2.48a
v2.48
v2.47
v2.46
v2.45
v2.44
v2.43
v2.42a
v2.42
v2.41
v2.40
v2.37a
v2.37
v2.36
v2.35a
v2.35
v2.34
v2.33a
v2.33
v2.32
v2.31a
v2.31
v2.30
v2.28c
v2.28a
v2.28
v2.27
v2.26
v2.25
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
User Interface
Assignees
Clear assignees
No Assignees
9 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#76101
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?