Bug 192019

got more data, if I add english and hebrew in regional & languages no problem occurs, but when I add spanish the error happens.

What distribution do you use?

If you put English on top, everything should be in English, the others being only fallbacks. I just tried with French and Arabic in trunk and it works OK. This will allow you change the language per application using the Help -> Switch Application Language... dialog but should leave everything in English.

You said "got more data, if I add english and hebrew in regional & languages no problem occurs, but when I add spanish the error happens."
When you add Spanish, do you then put English back as top language? Do you see systemsettings GUI language change as you do? Can you add a screenshot of SystemSettings dialog with the 3 languages please?

(In reply to comment #2)
> What distribution do you use?
> 
> If you put English on top, everything should be in English, the others being
> only fallbacks. I just tried with French and Arabic in trunk and it works OK.
> This will allow you change the language per application using the Help ->
> Switch Application Language... dialog but should leave everything in English.
> 
> You said "got more data, if I add english and hebrew in regional & languages no
> problem occurs, but when I add spanish the error happens."
> When you add Spanish, do you then put English back as top language? Do you see
> systemsettings GUI language change as you do? Can you add a screenshot of
> SystemSettings dialog with the 3 languages please?

I use gentoo, adding english and hebrew causes no problems, but the minute I add spanish, no matter if I select english on top, the description is still n spanish whereas the gui is in english.
strangely, I'm unable to repreduce it right now, will try on my new profile and report backm,y findings.

I can confirm, using US English followed by German as a secondary language.  I will attach a screenshot so you can see what the reporter is referring to.

I also see the problem in displayed mimetypes (not just in Dolphin, but basically anywhere, including KFileDialog).

Created attachment 34818 [details]
Screenshot of English + occasional German

This screenshot shows US English pretty much everywhere, except for the left sidebar, which shows up translated into German.  This is with US English and German languages available in the Regional settings, with US English as the priority.

I don't reproduce, nor with US English as 1 and French as 2 or with US English as 1 and German as 2. I restarted KDE to be sure after setting German as second language. I don't see a word of German anywhere.

Does the bug happens as soon as you set German as second language?

Maybe this is triggered by some global variables related to languages, mine from set are
LANG=en_GB                                                                         
LANGUAGE=en_GB:en                                                                  
LC_ADDRESS=fr_FR                                                                   
LC_COLLATE=en_GB                                                                   
LC_CTYPE=en_GB                                                                     
LC_IDENTIFICATION=fr_FR                                                            
LC_MEASUREMENT=fr_FR                                                               
LC_MESSAGES=en_GB                                                                  
LC_MONETARY=fr_FR                                                                  
LC_NAME=fr_FR                                                                      
LC_NUMERIC=fr_FR                                                                   
LC_PAPER=fr_FR                                                                     
LC_SOURCED=1                                                                       
LC_TELEPHONE=fr_FR                                                                 
LC_TIME=en_GB

Created attachment 34856 [details]
screenshot of mixed languages (mostly english in spite of language settings)

I am having this problem the other way around. I want German localization and it is the only language set in systemsettings, but menues, toolbars etc. still stick to English. Some other strings are translated, though. Specifying en_US as the second language does not change anything (it should not anyway). For an example see my attached screenshot.

I am also using gentoo (amd64) and have seen this behaviour ever since I set up this computer (kde 4.2.x | x>0).

Skander, it looks like you did not restart SystemSettings after you set German. You need to restart any app before it is fully localized.
Michael, the bug reporter, do you also experiment Skander's bug when you set only German?

I did. By now I even restarted my computer. As in the past it did not help at all, KDE and SystemSettings still look exactly the same.

Skander, I think this is on your system, I asked on IRC and Gentoo users with German do not reproduce this for System Settings for example. ENglish is only present when German translations are missing.

I cannot reproduce any of the problems on my system (self build from KDE sources) If I set German on top in System Settings, I get all German, if I set English on top then German, I get all in English. I also use KDE in French to check French translations and only get English words when the translation to French is missing. I never heard of such a problem except with Ubuntu installations when Ubuntu do not ship KDE translations but some own translations files.

annma,  when I set only German I get the German strings but most of the strings on the spell checking and keyboard layout dialogs are still untranslated (I'm not sure if that's due to missing translation or not though :-/)

I will say that I didn't see this the bug that was reported until I had setup German as a second language to US English.  When it was just US English everything was fine, now mimetypes and some other strings get translated even though German has been removed from the list.

Only thing I can think of is that adding a language tweaks some flags/settings that are not updated when removing a language from the list?

I'm not using germen, I think the issue is when adding second layout other than english which is latin based

Created attachment 34881 [details]
System Settings Keyboard Layout in German as top language

OK I can indeed reproduce now the Type translation problem. Settings French on top then switching to English US as first and French second, the type in a Properties file is still in French.
See attached screenshot.

Same for some elements in KHelpCenter but not the same as you Michael.
Also screenshot attached

If I remove the second language in SystemSettings then the problems get fixed (if I only keep English US then the French part in Dolphin Properties, Type: disapeears.

Created attachment 34887 [details]
The Type property is still in French while in SystemSettings English US is first language and French second.

Created attachment 34889 [details]
Some KHelpCenter entries are in French in the content index with a UTF8 problem. EnglishUS is first language is SystemSettings and French is second.

CCing Chusslove Illich who is l10n guru.
Chusslove, can you please have a look to that bug and re-assign it to the right component? Thanks a lot!

great, that is exactly what I see.

I think all the problematic strings on screenshots come not from PO files at
runtime, but from other, special sources (.desktop files, documentation
stack...) There should be no problem with English on top for strings from
runtime POs, but these special sources are questionable, as English may be
incorrectly treated as "raw source string, look for translation".

On the other hand, English on top (as opposed to English-only) is a strange
setting, and I don't think it's worth the time to examine every problematic
code path and see what and how to fix to honor it -- that would make this
bug "won't fix". Stompdagger1, what's your reason for English-Hebrew-
Spanish, instead of just English?

the fact that I'm not the only one that is using the computer and they speak hebrew/spanish better than english...

I understand the low severity of this issue but marking this as wont fix is disrespecting users by releasing a program with a known bug.
that is something I came to expect from oses like windows and osx but not from the open source community. think of the repercussion when an outsider sees that minor bugs are been ignored in kde, what should he think on major bugs that are hard to track down.

I urge you not to mark it has won't fix and not ignoring this issue.

on the other hand, why were this feature designated for?

Do we have a misunderstanding here? A bug of this magnitude in the ordering
(from top to bottom) Spanish-Hebrew-English or Hebrew-Spanish-English would
be something for which the release of the whole of KDE would be delayed
until fixed. The odd ordering, the one which I don't understand the need
for, and therefore asking you why you are using it, is English-Whatever-
Whatever.

If the same computer (and account) is used by different speaking users Engligh-Somelanguage-Someotherlanguage is not uncommon. One user knows a language, the other another one, the other from the list only Enligh. Actually I have a setup like that in a public place (running KDE3) where on login they select the language, and in that case the order can be anything, like English-Hungarian-Romanian or Hungarian-English-Romanian, etc.

(In reply to comment #21)
> Do we have a misunderstanding here? A bug of this magnitude in the ordering
> (from top to bottom) Spanish-Hebrew-English or Hebrew-Spanish-English would
> be something for which the release of the whole of KDE would be delayed
> until fixed. The odd ordering, the one which I don't understand the need
> for, and therefore asking you why you are using it, is English-Whatever-
> Whatever.

I've never said that this bug should in anyway delay the entire release.
what I've said that by labeling this bug has "wont fix", the bug will not be resolved in later releases. all I'm saying is that, due to the minority of the bug, it should be fixed, when? it is up to you to decide because you are the one incharge of this. again, I have more then one users on the computer, not much of space and I don't want to dedicate unneeded space allocation for another 2 profiles.
in the bottom line, what ever you decide, we will have to accept it.

SVN commit 989334 by ilic:

Do not automatically push English to lowest priority, honor user settings.
CCBUG: 192019


 M  +2 -2      kdebase/runtime/khelpcenter/view.cpp  
 M  +2 -2      kdelibs/kdecore/localization/klocale.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=989334

SVN commit 989336 by ilic:

When a comment does not have a language set, assume and explicitly store it
as English. Otherwise, English is getting overriden if higher by priority
then another language which also has a comment in it.
CCBUG: 192019


 M  +5 -4      kbuildmimetypefactory.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=989336

I've fixed the two bugs clearly demonstrated by Anne-Marie's screenshots.
Other issues are probably due to caching of stuff, so log out/in, possibly
delete everything in ~/.kde/cache-*/ if relogging doesn't work.

In general, switching language, or any other setting, under the same account
all the time, due to different users using that same account, is very poor
usage habit on a multiuser operating system (with the possible exception of
Andras' case of a public machine, where I've no idea what the best practices
are...) I hope these fixes do not encourage it.

I'd rather not close the bug yet, in case there is something more amiss.

thanks for the update, as soon as I can get the chance to test it, I'll try and post my findings.

Unfortunately neither deleting the cache-directory nor moving away .kde (and .kde4) nor updating to 4.3RC1 made my language mix go away. Any idea where I could start looking for solutions? Are there system variables that override settings made within kde that need to have a certain value?

Skander, Chusslove's fixes were revisions 989334 through 989337 so you need to make sure your kdelibs is more recent.  You said you were testing RC1 but according to Websvn, the tag for kdelibs was created 10 days ago and is only up to 986427.

Or in other words you need to update to latest 4.3 branch or trunk to test.

I finally found out more , parts of the localization seem to depend on the value of the LANG environment variable.

LANG=de_DE.utf-8:
KDE is completely localized, everything is German or English, depending on language settings in systemsettings

LANG=en.utf-8:
LANG=some language not present on my system:
LANG not set/unset:
KDE is either completely in English (if set to English in systemsettings) or a mix of German and English if set to German.

I had LANG set to de_DE.utf-8 - but only for my normal user (using ~/.bashrc). When starting KDE from within kdm, it is set to the systemwide default, wich was not set in my case.

For anything regarding locales to function properly (application language
included), LANG or LC_ALL have to be set to an existing system locale (they
can be listed by locale -a). (LC_ALL has higher priority than LANG.)

*** This bug has been marked as a duplicate of bug 327757 ***

Can still reproduce by making American English the top language and adding any other languages.

In this case, I should never see text from any other languages, because American English is by definition 100% complete since it's the language that all other languages are translated from. It has no missing strings. However instead GUI apps and CLI programs display a mix of languages.

*** Bug 427773 has been marked as a duplicate of this bug. ***

*** Bug 429273 has been marked as a duplicate of this bug. ***

*** Bug 410139 has been marked as a duplicate of this bug. ***

*** Bug 419911 has been marked as a duplicate of this bug. ***

*** Bug 426473 has been marked as a duplicate of this bug. ***

From BUG 437565:

Setting “LANGUAGE=en_US” (just one language) or “LANGUAGE=C:fr:ko” fixes the command line.  I suppose that few packages have any “en” localizations, and rely on the fall-back “C” strings to serve English users.

Perhaps kcm_language should never put an English locale by itself in LANGUAGE; it should always follow it with C, as in “LANGUAGE=fr:en_CA:C:ko”.

*** Bug 437565 has been marked as a duplicate of this bug. ***

*** Bug 422636 has been marked as a duplicate of this bug. ***

*** Bug 417420 has been marked as a duplicate of this bug. ***

*** Bug 435852 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #39)
> Perhaps kcm_language should never put an English locale by itself in
> LANGUAGE; it should always follow it with C, as in “LANGUAGE=fr:en_CA:C:ko”.

... more specifically, follow the right-most English locale: "LANGUAGE=fr:en_CA:en_GB:en:C:ko"

Yeah, makes sense. Should be a simple fix. I can look into it.

*** Bug 416771 has been marked as a duplicate of this bug. ***

And from Bug 416771:

The problem seems to be that many GTK apps don't explicitly name or alias their English locale as "en" or "en_US", but instead make it the default locale, which is "C".  For these apps if you have "LANGUAGE=en_US" it will try to find the en_US locale, fail, and fallback to the default locale, C, which just usually happens to be English, so it *seems* to work.  But if you have "LANGUAGE=en_US:zh_CN" it tries to find en_US, fails, moves onto zh_CN, finds it, and so displays Chinese.  This can be verified by using "LANGUAGE=C:zh_CN", which for most GTK apps should cause them to display English.  Or at least *mostly* English: for Evolution it causes some fields/labels to be in Chinese.

Possible solutions:

1) When generating plasma-localerc, try to guess a good place to insert "C" into LANGUAGE.

2) In the "Configure Plasma translations" GUI, have a "GTK default" language which will be second in the list when plasma-localerc has no [Translations] section.  The user can then change its position in the list or delete it.


---


#1 is similar to the already-proposed idea, which I like because it will be invisible to users and we won't have to explain all this stuff in the UI. I'll try to block out some time to work on that.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087

*** Bug 445450 has been marked as a duplicate of this bug. ***

*** Bug 447783 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #47)
> And from Bug 416771:
> 
> The problem seems to be that many GTK apps don't explicitly name or alias
> their English locale as "en" or "en_US", but instead make it the default
> locale, which is "C".  For these apps if you have "LANGUAGE=en_US" it will
> try to find the en_US locale, fail, and fallback to the default locale, C,
> which just usually happens to be English, so it *seems* to work.  But if you
> have "LANGUAGE=en_US:zh_CN" it tries to find en_US, fails, moves onto zh_CN,
> finds it, and so displays Chinese.  This can be verified by using
> "LANGUAGE=C:zh_CN", which for most GTK apps should cause them to display
> English.  Or at least *mostly* English: for Evolution it causes some
> fields/labels to be in Chinese.
> 
> Possible solutions:
> 
> 1) When generating plasma-localerc, try to guess a good place to insert "C"
> into LANGUAGE.
> 
> 2) In the "Configure Plasma translations" GUI, have a "GTK default" language
> which will be second in the list when plasma-localerc has no [Translations]
> section.  The user can then change its position in the list or delete it.
> 
> 
> ---
> 
> 
> #1 is similar to the already-proposed idea, which I like because it will be
> invisible to users and we won't have to explain all this stuff in the UI.
> I'll try to block out some time to work on that.

From my understanding C should mean "untranslated", so the above behaviour is expected and a bug report should be filed to the appropriate software for not coming with English translation.

Yes, tons of apps treat C as "American English" instead of having an explicit en_US translation. That's the cause of this issue.

Unfortunately we can't fix the world especially for such a widespread issue. Feel free to follow up with the apps in question, but from the Plasma perspective, all we can do is either warn people about it or prevent configuring it this way.

This comment in my merge request seemed to sum it up nicely:

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087#note_313992
> In a way, this is a work-around for a bug in society.  Most programmers put English strings
> in the C locale, assume that they can fall back to C, and hence don't bother to provide full
> English localizations.  That only works if English is at the end of the LANGUAGE variable.
> The resulting feedback loop makes C an English locale in practice.

*** Bug 452714 has been marked as a duplicate of this bug. ***

*** Bug 456050 has been marked as a duplicate of this bug. ***

Git commit 134e2d5c989c36ac0e985ee0ae382996c6b7b56e by Han Young.
Committed on 02/07/2022 at 09:29.
Pushed by hanyoung into branch 'master'.

merge Language and Formats
Related: bug 341235, bug 344588, bug 394477, bug 397974, bug 397975, bug 403580, bug 417564, bug 420268, bug 429474, bug 431292, bug 444772, bug 446785, bug 447787, bug 448324, bug 448355, bug 451919, bug 451944, bug 454991

closes https://invent.kde.org/plasma/plasma-workspace/-/issues/23

M  +1    -0    .kde-ci.yml
M  +52   -8    CMakeLists.txt
M  +2    -1    config-workspace.h.cmake
D  +0    -2    doc/kcontrol/formats/CMakeLists.txt
D  +0    -63   doc/kcontrol/formats/index.docbook
R  +1    -1    doc/kcontrol/region_language/CMakeLists.txt [from: doc/kcontrol/translations/CMakeLists.txt - 063% similarity]
R  +-    --    doc/kcontrol/region_language/go-top.png [from: doc/kcontrol/translations/go-top.png - 100% similarity]
R  +36   -23   doc/kcontrol/region_language/index.docbook [from: doc/kcontrol/translations/index.docbook - 050% similarity]
A  +-    --    doc/kcontrol/region_language/list-remove.png
D  +-    --    doc/kcontrol/translations/list-remove.png
M  +1    -2    kcms/CMakeLists.txt
D  +0    -30   kcms/formats/CMakeLists.txt
D  +0    -5    kcms/formats/Messages.sh
D  +0    -61   kcms/formats/formatssettings.kcfg
D  +0    -80   kcms/formats/kcmformats.cpp
D  +0    -34   kcms/formats/kcmformats.h
D  +0    -183  kcms/formats/localelistmodel.cpp
D  +0    -140  kcms/formats/optionsmodel.cpp
D  +0    -126  kcms/formats/package/contents/ui/main.qml
A  +75   -0    kcms/region_language/CMakeLists.txt
A  +8    -0    kcms/region_language/Messages.sh
R  +2    -27   kcms/region_language/exampleutility.cpp [from: kcms/formats/exampleutility.cpp - 052% similarity]
A  +22   -0    kcms/region_language/exampleutility.h     [License: GPL(v2.0+)]
A  +82   -0    kcms/region_language/kcm_regionandlang.desktop [TRAILING SPACE] ** [TRAILING SPACE] **
R  +4    -4    kcms/region_language/kcm_regionandlang.json [from: kcms/formats/kcm_formats.json - 098% similarity]
A  +250  -0    kcms/region_language/kcmregionandlang.cpp     [License: GPL(v2.0+)]
A  +58   -0    kcms/region_language/kcmregionandlang.h     [License: GPL(v2.0+)]
A  +372  -0    kcms/region_language/languagelistmodel.cpp     [License: GPL(v2.0+)]
A  +100  -0    kcms/region_language/languagelistmodel.h     [License: GPL(v2.0+)]
A  +30   -0    kcms/region_language/localegenerator.cpp     [License: LGPL(v2.0+)]
A  +17   -0    kcms/region_language/localegenerator.h     [License: LGPL(v2.0+)]
A  +19   -0    kcms/region_language/localegeneratorbase.cpp     [License: GPL(v2.0+)]
A  +23   -0    kcms/region_language/localegeneratorbase.h     [License: GPL(v2.0+)]
A  +32   -0    kcms/region_language/localegeneratorglibc.cpp     [License: GPL(v2.0+)]
A  +24   -0    kcms/region_language/localegeneratorglibc.h     [License: GPL(v2.0+)]
A  +101  -0    kcms/region_language/localegeneratorubuntu.cpp     [License: GPL(v2.0+)]
A  +27   -0    kcms/region_language/localegeneratorubuntu.h     [License: GPL(v2.0+)]
A  +36   -0    kcms/region_language/localegenhelper/CMakeLists.txt
A  +187  -0    kcms/region_language/localegenhelper/localegenhelper.cpp     [License: GPL(v2.0+)]
A  +46   -0    kcms/region_language/localegenhelper/localegenhelper.h     [License: GPL(v2.0+)]
A  +20   -0    kcms/region_language/localegenhelper/org.kde.localegenhelper.conf
A  +21   -0    kcms/region_language/localegenhelper/org.kde.localegenhelper.policy
A  +8    -0    kcms/region_language/localegenhelper/org.kde.localegenhelper.service.in
A  +158  -0    kcms/region_language/localelistmodel.cpp     [License: GPL (v2+)]
R  +22   -22   kcms/region_language/localelistmodel.h [from: kcms/formats/localelistmodel.h - 060% similarity]
A  +197  -0    kcms/region_language/optionsmodel.cpp     [License: GPL(v2.0+)]
R  +21   -11   kcms/region_language/optionsmodel.h [from: kcms/formats/optionsmodel.h - 054% similarity]
A  +204  -0    kcms/region_language/package/contents/ui/AdvancedLanguageSelectPage.qml     [License: LGPL(v3.0+)]
A  +238  -0    kcms/region_language/package/contents/ui/main.qml     [License: LGPL(v3.0+)]
A  +64   -0    kcms/region_language/regionandlangsettings.cpp     [License: GPL(v2.0+)]
A  +21   -0    kcms/region_language/regionandlangsettings.h     [License: GPL(v2.0+)]
A  +37   -0    kcms/region_language/regionandlangsettingsbase.kcfg
R  +2    -2    kcms/region_language/regionandlangsettingsbase.kcfgc [from: kcms/formats/formatssettings.kcfgc - 055% similarity]
A  +17   -0    kcms/region_language/settingtype.h     [License: GPL(v2.0+)]
D  +0    -49   kcms/translations/CMakeLists.txt
D  +0    -2    kcms/translations/Messages.sh
D  +0    -191  kcms/translations/language.cpp
D  +0    -32   kcms/translations/language.h
D  +0    -312  kcms/translations/package/contents/ui/main.qml
D  +0    -86   kcms/translations/translations.cpp
D  +0    -53   kcms/translations/translations.h
D  +0    -193  kcms/translations/translationsmodel.cpp
D  +0    -72   kcms/translations/translationsmodel.h
D  +0    -27   kcms/translations/translationssettings.cpp
D  +0    -24   kcms/translations/translationssettings.h
D  +0    -28   kcms/translations/translationssettingsbase.kcfg
D  +0    -6    kcms/translations/translationssettingsbase.kcfgc

The files marked with ** at the end have a problem. Either the file contains a trailing space or the file contains a call to potentially dangerous code. Please read: https://community.kde.org/Sysadmin/CommitHooks#Email_notifications for further information. Please either fix the trailing space or review the dangerous code.


https://invent.kde.org/plasma/plasma-workspace/commit/134e2d5c989c36ac0e985ee0ae382996c6b7b56e

*** Bug 465373 has been marked as a duplicate of this bug. ***

Created attachment 156049 [details]
still happens

This bug isn't fixed for good as shown in the attached image and my duplicate bug report, but a fix seems impossible to do in a satisfactory way. What has happened is the implementation of a warning in the Language&Region KCM when en_US is the top language which says that:

"Putting American English above other languages will cause undesired behavior in some applications. If you would like your system to use American English, remove all other languages."

The reason it can't be fixed is that even en_US isn't necessarily 100% complete because many programs rely on falling back to C for English and don't have en_US strings, while rarely some others will have a non-English language as their "unlocalized C". This means "C" can't simply be appended in a suitable place as a catch-all solution to always show English. For more details:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087

In this issue is deemed action-worthy or actionable at all, this bug can be reopened.

So the way we "solved" this was to put in a warning message not to add any non-English languages below English.

But we only did this for American English! We need to do it for the other Englishes as well, like British English and Australian English. Because the same thing happens there too, if your language list ends up looking like en_GB:de_DE. This is invalid, but the user won't know unless we tell them.

If this still isn't enough, we might want to reconsider https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087 and always internally insert "C" after the last en_* language in the list. There was discussion in there about maaaaybe having to do it anyway but hopefully a warning message is enough. So let's start by fixing this issue with the warning message not appearing for other English languages and then see where that leaves us.

Looks like that's tracked in Bug 465449, so I'll go fix that.

I was going to create another bug entry, but I think it's better is this go here?

Product: Kate
Component: Application
Version: 24.2.0


STEPS TO REPRODUCE
1. Open Configuration -> Configure Language
2. Add a secondary language and restart
3. 

OBSERVED RESULT
Parts of the interface and menu are displayed in the secondary language.

EXPECTED RESULT
All elements of the interface and the menus should be displayed only in the primary language.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Neon User
(available in About System)
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0
Qt Version: 6.6.2

ADDITIONAL INFORMATION
This problem isn't limited to KWrite or Kate, I think this affects Gear Programs in general. 
I think this was caused because I had added a secondary language in System Settings, but even after removing the secondary language the problem persists because Gear Programs have their own language configuration.
Also, if adding a secondary language in System Settings adds secondary languages to Gear Programs, removing the secondary language in System Settings should also remove from Gear Programs, automatically.
Another thing I noticed, duplicated secondary languages. KWrite had 5 of the same secondary languages added to the list, Kate and Dolphin and 1 and 2.

It seems it happens with any language you are as secondary and the degree it affects elements of the interface vary with each program.