Bugzilla

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support on several occasions. The menu entry has never been known to the user in the support cases I have worked on.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language recognition. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that speech recognition is better in any case. Honestly, I don't know which is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided with a present lang attribute, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language recognition. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that speech recognition is better in any case. Honestly, I don't know which is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided with a present lang attribute, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on. Also, users do not necessarily understand why no icon is displayed when they can see that the language is not their own.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language recognition. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that speech recognition is better in any case. Honestly, I don't know which is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided with a present lang attribute, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on. Also, users do not necessarily understand why no icon is displayed when they can see that the language is not their own.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language detection. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that speech recognition is better in any case. Honestly, I don't know which is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided with a present lang attribute, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on. Also, users do not necessarily understand why no icon is displayed when they can see that the language is not their own.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language detection. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that language recognition is better in any case. Honestly, I don't know which is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided with a present lang attribute, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on. Also, users do not necessarily understand why no icon is displayed when they can see that the language is not their own.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language detection. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that language detection is better in any case. Honestly, I don't know which is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided with a present lang attribute, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on. Also, users do not necessarily understand why no icon is displayed when they can see that the language is not their own.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language detection. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that language detection is better in any case. Honestly, I don't know which approach is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided with a present lang attribute, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on. Also, users do not necessarily understand why no icon is displayed when they can see that the language is not their own.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language detection. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that language detection is better in any case. Honestly, I don't know which approach is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided if a lang attribute is present, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on. Also, users do not necessarily understand why no icon is displayed when they can see that the language is not their own, while on others websites in the same language they see the icon.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language detection. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that language detection is better in any case. Honestly, I don't know which approach is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language recognition is avoided if a lang attribute is present, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.

It appears that no language detection of the content takes place if the lang attribute is set in the HTML of the website. Unfortunately, this does not always match the actual language. The result is that no translation is offered via an icon in the address bar. This has already caused confusion in Firefox support a few times. The menu entry has never been known to the user in the support cases I have worked on. Also, users do not necessarily understand why no icon is displayed when they can see that the language is not their own, while on others websites in the same language they see the icon.

Unfortunately, bug 1888824 (always showing the icon in the address bar)  was rejected. Another approach could be to always perform language detection. This would reduce the need for bug 1888824.

I don't know if the decision to prioritize the lang attribute over language detection is due to performance implications or is a conceptual decision because the assumption is that the attribute is more likely to be correct.

I don't want to argue that language detection is better in any case. Honestly, I don't know which approach is more likely to give the correct language. I'll leave it up to you to decide whether it's better to always prioritize the lang attribute or the recognized language.

But if no general change is desired, perhaps the icon could at least be displayed in the address bar if there is a mismatch between the attribute and the recognized language?

If there are performance reasons why language detection is avoided if a lang attribute is present, could the language detection perhaps be made optional? I know how important performance is. But my experience is also that some people prefer convenience (quick access to the translation feature) to a performance impact that they don't notice anyway.