Default language makes no sense
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
I recently updated from version 4.2.2 to 4.2.3 and suddenly the default language is Spanish.
I have configured PhpGedView to use Swedish, English, Spanish. My default language setting for the gedcom is Swedish. My browser preferred languages are Swedish / English (US) in that order, and same problem occurs in both Firefox and IE…
When I log in I get the correct language as set for my user, but default for logged out is Spanish, unless of course, I disable Spanish language… cos then it shows in Swedish language as the config files specify… Makes perfect sense not!!! If I add all the other languages it still shows Swedish… except if I add some kind of Spanish too… Both the normal and the south american variety give same effect…
Before the update all was OK but I know I had some similar problems after installing 4.2.2 also.. but no clue about the solution… it's like it chooses Spanish over Swedish, when Spanish is available… otherwise it's ok with Swedish… why and how nobody knows…
<<but default for logged out is Spanish>>
Default for logged out is a gedcom configuration setting. You didn't say what value you had selected for this.
if u read again it says… "My default language setting for the gedcom is Swedish." but it does not care as long as Spanish is available to choose from…
Sorry. I read your post twice and missed that bit.
i had similar problem with 4.2.2 but somehow i was able to fix it… but I do not remember now exactly how I did it… possibly i did a full reinstall and configuration and by chance it happened to work then…. does not make sense though…
More strange is that the default language after a clean install with 4.2.2 was also Spanish for me… not English which would make a lot more sense for an unconfigured system… or Swedish, provided that it really reads the browser settings in the right way… which i seriously doubt considering what i get here…
during install of 4.2.2 I was forced to make the initial configuration using Spanish dialogs in the config page… not easy but I was able to guess what was supposed to be entered where at least… :-) until I had configured it to use at least english…
My website now been tested on an English language windows PC in other country… it correctly shows english as default… so maybe this is a problem which only exists for users of Swedish language browsers on Swedish language operating systems… it's same problem for Firefox on Ubuntu here in Sweden too… easy solution is to disable Spanish on the page…
Could it be a simple typing error in the file which chooses language according to browser preferences? so that Swedish language code gives Spanish language? might be worth investigating… mysterious it is for sure… since it only happens when Spanish language is enabled…
I wonder if Spanish serving es-sv (Spanish in El Salvador) is triggering a substring parsing bug…
Try to remove es-sv from the list for Spanish in includes/lang_settings.php to see if it helps…
Yes!!!
That fixed the problem… but it also suggests that the PhpGedView developers should make some fixes in the language selection code in modules/session.php, so that it can not confuse sv with es-sv. It need take into account the special varieties in some other way… simple pattern matching obviously does not do the trick… Similar issues might occur for other languages if the language codes are not used for one and only one language… sv should never ever be used for anything else than Swedish I think…
I mean they need change includes/session.php of course…
I have posted a bug report about this issue
Language code are standardized by international convention, (for example)
es-mx Spanish (Mexico)
es-gt Spanish (Guatemala)
es-cr Spanish (Costa Rica)
es-pa Spanish (Panama)
es-do Spanish (Dominican Republic)
es-ve Spanish (Venezuela)
es-co Spanish (Colombia)
es-pe Spanish (Peru)
es-ar Spanish (Argentina)
es-ec Spanish (Ecuador)
es-cl Spanish (Chile)
es-uy Spanish (Uruguay)
es-py Spanish (Paraguay)
es-bo Spanish (Bolivia)
es-sv Spanish (El Salvador)
es-hn Spanish (Honduras)
es-ni Spanish (Nicaragua)
es-pr Spanish (Puerto Rico)
This is to say (for clarity) the bug is with the pattern match not looking for "sv" alone as opposed to "sv" preceded by or coming before any additional letters. "sv" can be found in a language code for El Salvadorian Spanish.
And Swedish spoken in Finland (sv-fi)
Yes that's exactly my point too, the pattern match can not be used as it it, because it sees no difference between sv and es-sv and potentially it can give problems for new languages which may be added later also…
yes but for sv-fi there is no problem, since if someone uses sv-fi as preferred language in a browser it will never match es-sv anyway… the problem is valid for all main 2 letter language codes which may be matched inside an extended language code… so the best fix is to recode the detection routine so it matches the full length of the codes… not only partial matches…
For example Arabic (ar) may be detected as Spanish for Argentina (es-ar) if someone chooses to use both Arabic and Spanish on his/her site… and there are many other potential conflicts…
The order in which the languages are defined in lang_settings.php may also have some impact, Spanish is defined ahead of Swedish so in my case it matches Spanish before it has a chance to match against Swedish.
Simply changing the order of the definitions may solve some problems… but it may not always be possible to move in such a way that all conflicts are gone for all the possible languages which may be included in the future… so recoding and making sure the match is made on full code length is highly recommended…
Actually sv-fi could be a problem if a user expects standard Swedish settings and they instead get a Finnish version of the Swedish setting. I'm not an expert in what PGV does but in other applications I seen where different words are need for the same root language but with country or local differences.
well it could be problem in other cases but in PGV, the sv and sv-fi are defined as the same language Swedish… the definition simply sets the main code and extended codes for a language, in one string with semicolons between the codes… the match occurs anywhere inside that string… that is why it matches sv with es-sv… there is no check that the codes between the semicolons have same length as the code they compare to…
If people get "real" Swedish or Finnish Swedish is a minor issue compared to what happens when you get a completely different language…
a string "guest" would for example give a match if you wanted Spanish language… the es is there… so it's a very primitive system but probably chosen cos it's much simpler and quicker than breaking up the string into pieces between the semicolons before comparing the full length codes
We do in PGV us es-ar (Spanish in Argentina) as a language option.
Yes your example is more devastating but not any more wrong than missing "sv-fi". In Norway many Nynorsk speakers can understand Bokmal and for that matter a lot of Danish and Norwegians can understand Swedish. I can understand British English (no offense, should I say real English :-) ) but we may someday need to have a language file that uses words that are more appropriate for a term in the US vs. England or Swedish vs. Swedish-in-Finland.
yes of course… if there are major differences those sub languages may have been included in PGV as separate languages… then u get what u want anyway.. but swedish and finnish swedish is exactly the same…
only difference being that u always hear if it's a Finn who speaks Swedish… they sound the same no matter what language they attempt… :-)
Fixed in SVN 6950