Bug 43508 - MainBundle.Localizations wrong output
Summary: MainBundle.Localizations wrong output
Status: RESOLVED ANSWERED
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Library (Xamarin.Mac.dll) ()
Version: 2.10.0 (C8)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Chris Hamons
URL:
Depends on:
Blocks:
 
Reported: 2016-08-18 12:33 UTC by Max Miroshnikov
Modified: 2016-08-26 17:08 UTC (History)
1 user (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test project (351.69 KB, application/zip)
2016-08-18 18:02 UTC, Max Miroshnikov
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description Max Miroshnikov 2016-08-18 12:33:29 UTC
NSBundle.MainBundle.Localizations returns wrong number of available localisations is case if CFBundleLocalizations specified in Info.plist. 

Case 1
CFBundleLocalizations not specified. In this case NSBundle.MainBundle.Localizations returns correct number of localisations - i.e. all different *.lproj from project.

Case 2
CFBundleLocalizations specified. In this case NSBundle.MainBundle.Localizations returns number of different *.lproj from project + all items from CFBundleLocalizations. This is wrong.

E.g. we have

/Resources
 /de.lproj
 /en.lproj
 /ru.lpoj   

and inside Info.plist:
.....
<key>CFBundleLocalizations</key>
<array>
  <string>en</string>  
</array>
....

In this case NSBundle.MainBundle.Localizations returns 4 elements: 
locs	{string[4]}	string[]
[0] 	"en"       	string
[1] 	"de"       	string
[2] 	"en"       	string
[3] 	"ru"       	string


Tested on latest alpha release.
Xamarin Studio Community
Version 6.1 (build 5338)
Runtime:
	Mono 4.6.0 (mono-4.6.0-branch/e571108) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)
Comment 1 Chris Hamons 2016-08-18 15:00:47 UTC
So our binding in this area is a pass through to Cocoa:

https://github.com/xamarin/xamarin-macios/blob/master/src/foundation.cs#L8266

so I have a hard time believing this is directly our bug. Maybe things aren't being packaged the way Cocoa expects? 

Could you attach a small example project showing how you are bundling things? Building a quick obj-c version of your example and comparing behavior will be the quickest way to get to the bottom of this.
Comment 2 Max Miroshnikov 2016-08-18 18:02:49 UTC
Created attachment 17104 [details]
Test project

Test project:

Added 2 resources (en.lproj and ru.lproj). Also into Info.plist added <key>CFBundleLocalizations</key>
<array>
  <string>en</string>
</array>
Comment 3 Max Miroshnikov 2016-08-26 15:31:15 UTC
Chris, did you check test project?
Comment 4 Chris Hamons 2016-08-26 16:58:10 UTC
Unfortunately, the [NSBundle.mainBundle localizations] API does not act as you expect. This is Cocoa behavior and not Xamarin.Mac specific. I've attached a small example here, written in objective-c:

https://www.dropbox.com/s/6j06ta95fjnx7ix/LocalizationProofNative.zip?dl=0

As you can see, the array returns for entries in the info.plist and based on the items your project:


(lldb) po (NSString*)a[0]
en

(lldb) po (NSString*)a[1]
ru

(lldb) po (NSString*)a[2]
Base

(lldb) po (NSString*)a[3]
en
Comment 5 Max Miroshnikov 2016-08-26 17:07:21 UTC
OK, thanks. Looks like bug or very unexpected behaviour in theirs API, is it?
Comment 6 Chris Hamons 2016-08-26 17:08:13 UTC
Unsure. You are welcome to file a Radar with Apple, but I would not expect a speedy response. :)