Be sure you use leading and trailing rather than left and right for things that
can change in direction for RTL. There are some small set of cases where you
want left and right, but unless you’re aware of those, it’s best to always use
leading and trailing.
--
Gary L. Wade
http://www.garywade.co
https://github.com/schriftgestalt/LocalizationSuite
>>>
>>> It is very good at keeping existing translations.
>>>
>>> Best
>>> Georg Seifert
>>>
>>>
>>>> Am 27.05.2020 um 19:30 schrieb Rob Petrovec via Cocoa-dev
>
extract the current translated strings from the
nib files? Is that handled as part of the automatic conversion?
Eyal
> On 27 May 2020, at 22:50, Rob Petrovec wrote:
>
> Auto layout (not auto-resizing) is independent of localization. You don’t
> need to switch to auto layout to su
via Cocoa-dev
>>> :
>>>
>>> I have never used AppleGlot. However, I’m curious why you don’t set up a
>>> .lproj for each localization you support containing .strings files with
>>> your translated strings inside?
>>>
>>> —Rob
&
> On May 27, 2020, at 2:37 PM, Martin Wierschin wrote:
>
>> Auto layout (not auto-resizing) is independent of localization. You don’t
>> need to switch to auto layout to support Base localization
>
> It's true that autolayout has many benefits aside from loca
> Auto layout (not auto-resizing) is independent of localization. You don’t
> need to switch to auto layout to support Base localization
It's true that autolayout has many benefits aside from localization. But I'd
say it's only partially true that you can switch to Base.l
extract the current translated strings from the
nib files? Is that handled as part of the automatic conversion?
Eyal
> On 27 May 2020, at 22:50, Rob Petrovec wrote:
>
> Auto layout (not auto-resizing) is independent of localization. You don’t
> need to switch to auto layout to su
Auto layout (not auto-resizing) is independent of localization. You don’t need
to switch to auto layout to support Base localization. So you can convert your
nibs over to Base Localization with a couple clicks in Xcode, and then you just
need .strings and .stringdict files in your .lprojs
t all that's obsolete now.
>
> You ultimately should convert your nibs to Base.lproj. The current Xcode
> localization process is way better than the bad old days where you had to
> keep endless translated nibs in sync. The conversion job is a good amount of
> busy work, an
ouldn't move to auto resizing.
Eyal
> On 27 May 2020, at 20:30, Rob Petrovec wrote:
>
> I have never used AppleGlot. However, I’m curious why you don’t set up a
> .lproj for each localization you support containing .strings files with your
> translated strings inside?
>
&
rent Xcode
localization process is way better than the bad old days where you had to keep
endless translated nibs in sync. The conversion job is a good amount of busy
work, and autolayout may give you pain initially, but ultimately using
Base.lproj + autolayout + translated .strings files is mu
Rob Petrovec via Cocoa-dev
> :
>
> I have never used AppleGlot. However, I’m curious why you don’t set up a
> .lproj for each localization you support containing .strings files with your
> translated strings inside?
>
> —Rob
>
>
>> On May 27, 2020, at
I have never used AppleGlot. However, I’m curious why you don’t set up a
.lproj for each localization you support containing .strings files with your
translated strings inside?
—Rob
> On May 27, 2020, at 10:04 AM, Eyal Redler via Cocoa-dev
> wrote:
>
> Hi,
>
> It lo
Hi,
It looks like Apple has dropped support for AppleGlot under Catalina. The
latest version (from 2017) will not install on Catalina and links and mentions
to AppleGlot have been removed from their localisation page
(https://developer.apple.com/localization/).
It looks like Apple wants us to
It would be helpful to know what the unhelpful message was, and at what stage
of the process it came to you.
Also, what exactly are you doing for localization?
— F
> On Apr 21, 2015, at 5:32 PM, Peters, Brandon wrote:
>
> I am getting an error in iTunes Connect for my App pert
Hello,
I am getting an error in iTunes Connect for my App pertaining to the English
localization. English is the only language my app currently supports. The error
is not really helpful. Has anyone seen something similar?
___
Cocoa-dev mailing list
Hi,
Now that I am ready to drop 10.7 support in my app, I want to use Base
localization for nib localization.
I have converted my international xibs to strings with Xcode 5.0.2 but there is
an issue at runtime on OS X 10.9 : "Tool Tips" that are inside NSTableCellViews
are not
Sadly no, see:
https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPInternational/Articles/LanguageDesignations.html
language-dialectic_locale, but is used either as language-dialectic or
language_locale.
The problem seems to be that the Folders used to hold the Localized
I found that Localisation of Nibs AND Help impossible to get to work together.
The Documentation is also very old and misleading.
With the App Stores being multilingual, I would hope this would be quick and
simple, but it is not.
New Zealand/Australia is bad enough, but South Africa is nightmare
To add British English to your list of preferred languages for succeedingly
launched apps to choose from, launch System Preferences, go to the Language &
Text panel, choose the Language tab, and drag British English to the top of the
list. If British English is not in the list, click the Edit Li
How can we make the application to use locale based localization? The apple
documentation tells that first locale based folders are searched.
On Feb 3, 2013 9:45 PM, "Douglas Davidson" wrote:
> The localization used is determined by matching the AppleLanguages list
> against t
The localization used is determined by matching the AppleLanguages list against
the localizations available in the application's main bundle. In this case, the
top entry in AppleLanguages is en, so that is the localization that will be
used.
Douglas Davidson
On Feb 3, 2013, at 6:56 AM,
Yes i am launching the the application between changes to the region.
Not sure what is Application's preference domain? How can we set/unset this?
The output of the defaults command as below.
*$ defaults read com.yourcompany.Hello AppleLanguages*
2013-02-03 20:22:10.317 defaults[4084:903]
The do
> My project has
> 1. en_GB.lproj
> 2. en_US.lproj
> 3. en.lproj
> Directories. Each time even if I change region setting, always strings from
> en.lproj directory is displayed.
>
Are you relaunching your application between changes to the region?
Does your application’s preference domain have a
My project has
1. en_GB.lproj
2. en_US.lproj
3. en.lproj
Directories. Each time even if I change region setting, always strings from
en.lproj directory is displayed.
On Feb 3, 2013 2:03 AM, "Keith Duncan" wrote:
> >> 1. en-US
> >> 2. en-UK
> >> 3. en
>
> There is no en-UK locale ID, nor an en_UK,
>> 1. en-US
>> 2. en-UK
>> 3. en
There is no en-UK locale ID, nor an en_UK, the identifier for the United
Kingdom is GB.
en-GB refers to British English as used anywhere in the world
en_GB refers to Generic English as used in the United Kingdom
> Docs say to use an underscore, not a hyphen. Are
On 2 Feb 2013, at 15:26, Arun wrote:
> Even that does not work either.
Define doesn’t work, what are you doing and what are your expected results and
actual results?
Keith
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post a
Yes. I used underscores. The project directories are also correctly named
On Feb 2, 2013 10:44 PM, "Kyle Sluder" wrote:
> On Feb 2, 2013, at 7:25 AM, Arun wrote:
>
> > Hi All
> >
> > I have a sample cocoa application which i am trying to localize in 3
> > flavors.
> >
> > 1. en-US
> > 2. en-UK
>
On Feb 2, 2013, at 7:25 AM, Arun wrote:
> Hi All
>
> I have a sample cocoa application which i am trying to localize in 3
> flavors.
>
> 1. en-US
> 2. en-UK
> 3. en
Docs say to use an underscore, not a hyphen. Are you sure your .lproj
directories are correctly-named?
--Kyle Sluder
__
Even that does not work either.
On Sat, Feb 2, 2013 at 7:46 PM, Keith Duncan wrote:
>
> On 2 Feb 2013, at 10:39, Arun wrote:
>
> > What is the folder name for making the app on Mac to support Canadian
> > French localization? fr_CA is not working
>
> Try using fr-CA,
Hi All
I have a sample cocoa application which i am trying to localize in 3
flavors.
1. en-US
2. en-UK
3. en
The application just tries to set the title of the Window.
My language setting is "English" and region is "United kingdom".
Irrespective of region setting, always strings from "en.lproj"
On 2 Feb 2013, at 10:39, Arun wrote:
> What is the folder name for making the app on Mac to support Canadian
> French localization? fr_CA is not working
Try using fr-CA, fr_CA is Generic French as used in Canada, fr-CA is French
Canadian.
___
What is the folder name for making the app on Mac to support Canadian
French localization? fr_CA is not working
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the
I'm having trouble implementing auto layout based views that appear in popups
and open/save panels.
Due to increased verbosity, relative to the original English, in for some
localizations some views need to grow in size to fit their content. Currently,
if I create a NIB in IB (Xcode 4.5), and t
point me to a good
>> resource on problems with Localizing help files - or even, perhaps, suggest
>> what the problem might be?
>
> If you're building a help bundle, what you absolutely must have in order to
> get help pick up your localized version is (for each individual localiz
n is (for each individual localization) a
InfoPlist.strings containing (at a minimum)
HPDBookTitle = "";
Without this, you'll always get the development language.
Regards
Markus
--
__
Markus Spoettl
__
A weird issue this. I'm trying to Localize my app - and, mostly, it's worked
like a charm. For some reason though, the help always gets delivered in the
English version. I have tried reindexing the help files - and now I'm out of
ideas (Google wasn't much help either!). Can anyone point me t
not the target), and adding a new Localization. Adding a new localization
>> is really a project-wide function, not specific to a single file. This way
>> you can localize all of your localizable resources at the same time instead
>> of doing them one file at a time.
&g
Am 17.08.2012 um 18:59 schrieb Kelly Keenan :
> You should add new localizations to your project the same way that you add a
> new target by selecting the Project, going to the Info tab for the Project
> (not the target), and adding a new Localization. Adding a new localization
>
Hi all,
I am having some trouble supporting ES-MX language as language falls
back to Spanish when I boot my machine in "Espanol Latinoamerica", any help
is appreciated.
*Details *:
I have made provisions for both the language's by creating separate
ES-MX.lproj and Spanish.lproj. Although I h
On 4 Jun 2012, at 9:44 AM, Marc Respass wrote:
> As for App Store and iTunes, on iOS 5.1.1 (and as long as I can remember),
> those apps appear on my phone in Spanish. If I switch my language to English,
> they will be in English. They don't change depending on where I am and I
> completely agr
Hi John,
I am American but I've been studying Spanish for years so I run my Macs and
iDevices in Spanish but everything else is American (dates, punctuation, etc.).
It really sticks out (in a bad way) when an app is partially localized or,
based on my language setting, makes assumptions other t
Am 03.06.2012 um 13:24 schrieb John Tall:
> a user in Germany will get the entire apps in German even if
> the rest of the phone is configured to run in English.
This is not true as far as my iOS devices are concerned. I can switch it to any
language and the next app start will show the app in
The standard way to localize an app is based on the user's preferred language.
(on mac os x, the preferred language order of priority/availability )
Above and beyond that, you might have some case where your app has a reason to
enable setting the preferred language at the app preferences level, o
I believe AppStore's behavior is wrong and against Apple's own guidelines, that
clearly state, that user's preferences come always first.
My colleagues, friends, and I filed countless radars about iTunes and
AppStore...
cheers
g.
On Jun 3, 2012, at 1:24 PM, John Tall wrote:
> An obvious scen
App Store is simply a starting point...
On launch we adjust our UI based on the user preferences, a Canadian
user can be French Canadian, or if close to the border and commutes,
could choose US English or Canadian ad infinitum... our app
contains all (of our) supported localizations.
Hello.
We currently have an iOS app available in English. We have decided to
localize it into other languages, but first we wanted to look into how
other companies are doing it in order to determine what the best
practices would be.
When we looked at how Apple localizes their apps we found someth
ings and resize them accordingly and modify each frame.
8. For lookup of localization settings while running your app (i.e., the
string table and key being used), utilize some special setting, such as a
debug menu option or special modifier key toggle, and when retrieving the
actual string, return th
layout method, where the English (or say your Base
language) NIB objects are adjusted to the minimum size which is required
by the longest text in one of the available languages.
A while ago, I have written a web page which explains how to optimize
NIB layouts for localization.
http://w
I believe that the "single nib" approach has been made more viable by Auto
Layout in Lion, and expect to see more developers using "single nib" in the
future.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests
I have single NIBs but I have the labels "reloaded" on DidLoad from
NSLocalizedString. You still have to try every localization for text width and
appareance but I find it somewhat less time consuming that having different
NIBs (and reflect any change on an element in a NIB to all the
When in Rome, do as the Romans do": check what Apple does. As far
as I know, they are still localizing with multiple nibs.
- Check what the guys who will localize the software would rather use.
The localization solutions based on just localizing the strings have
some side issues:
- you abso
Hi,
currently my application supports only English. In the future versions we would
like to have it in around 15 languages.
What is the best practice for having localized nibs.
1) Common approach, different nibs for different languages.
+ve, straight forward.
-ve, Time consuming and maintenanc
On 8 Nov 2011, at 13:45, Gary L. Wade wrote:
> That's how it's always worked.
I just did show the font panel in TextEdit and looked at Arial:
10.5 shows Bold, Italic. etc. (English)
10.6 and 10.7 show Fett, Kursiv etc. (German).
So this NSFont behaviour (which I guess is used in the font pane
> Deutsch
>> Français
>> English
>>
>> what is a program supposed to do if it has:
>> en.lproj
>> de.lproj
>> but NOT en_GB.lproj ?
>>
>> I guess (but did not find an authoritative answer) that it should look for:
>> en_GB
>> en
should look for:
> en_GB
> en
> de
> fr
> en
> it's development language (Localization native development region =
> CFBundleDevelopmentRegion)
>
> But with my language settings -[NSFont displayName] returns German font names.
> Obviously NSFont does not have en_GB font names
should look for:
en_GB
en
de
fr
en
it's development language (Localization native development region =
CFBundleDevelopmentRegion)
But with my language settings -[NSFont displayName] returns German font names.
Obviously NSFont does not have en_GB font names, and it does NOT look into it's
Am 04.11.2011 um 00:31 schrieb Alexander Reichstadt:
> What's unexpected are two things:
> - my app still launches in English
> - the English.lproj contains the nib file I localized as e.g. MainMenu.nib,
> the German.lproj however still contains a MainMenu.xib
Make sure there is no MainMenu.nib
Hi,
there is a problem localizing the resources for my project.
The way I went about localizing the original English xib was to select it, add
a loc-language, then I localized it, cleaned the build and ran the app.
My system is running using German language as setup in system preferences and
v
Hi,
Many thanks. That worked perfectly.
I need this to allow my users to disable localization.
I use this:
- (IBAction) setDisableLocalization:(id) sender {
if ([sender state] == NSOnState) {
[[NSUserDefaults standardUserDefaults] setObject:[NSArray
arrayWithObject
On Wed, 6 Apr 2011 09:43:58 +0200, Felix Franz said:
>> I what to give my users the possibility to disable the localization of
>my app. Is there a way to tell the system (NSBundle?) to always load the
>english nibs?
>
>Just read http://homepage.mac.com/mmalc/Stepwise/Interna
On Apr 6, 2011, at 4:43 PM, Felix Franz wrote:
>
> On Apr 5, 2011, at 3:55 PM, Georg Seifert wrote:
>
>> Hi,
>>
>> I what to give my users the possibility to disable the localization of my
>> app. Is there a way to tell the system (NSBundle?) to always loa
On Apr 5, 2011, at 3:55 PM, Georg Seifert wrote:
> Hi,
>
> I what to give my users the possibility to disable the localization of my
> app. Is there a way to tell the system (NSBundle?) to always load the english
> nibs?
Just read http://homepage.mac.com/mmalc/Stepwise/Inter
Hi,
I what to give my users the possibility to disable the localization of my app.
Is there a way to tell the system (NSBundle?) to always load the english nibs?
Best
Georg___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post
.com wrote:
[...]
Of course, sorry. Instead of the localization value, I get the
localization key instead, which is an English string.
Here's a list of things to check:
- Check that there's no missing ';'
- Check that you do not have "key" ="something"
On Jan 27, 2010, at 3:05 PM, lorenzo7...@gmail.com wrote:
[...]
Of course, sorry. Instead of the localization value, I get the
localization key instead, which is an English string.
Here's a list of things to check:
- Check that there's no missing ';'
- Check that
On Jan 27, 2010 7:51am, Steve Bird wrote:
On Jan 27, 2010, at 8:42 AM, lorenzo7...@gmail.com wrote:
I'm not sure if this is an XCode or Cocoa issue, so I'm going to post
this question on both lists:
I'm adding localization strings to my application. So far, I
On Jan 27, 2010, at 8:42 AM, lorenzo7...@gmail.com wrote:
I'm not sure if this is an XCode or Cocoa issue, so I'm going to
post this question on both lists:
I'm adding localization strings to my application. So far, I've
added Spanish, French, Italian and English Local
I'm not sure if this is an XCode or Cocoa issue, so I'm going to post this
question on both lists:
I'm adding localization strings to my application. So far, I've added
Spanish, French, Italian and English Localizable.strings. When I change
languages, everyone one
On Dec 23, 2009, at 7:38 AM, Jerry Krinock wrote:
>
> Well, Ricky I see you're one of the few who has really thought through all
> the issues.
>
> On 2009 Dec 22, at 19:59, Kyle Sluder wrote:
>
>> On Tue, Dec 22, 2009 at 11:54 AM, Ricky Sharp wrote:
>>> * No plural forms (while allowing plur
2009/12/23 Jerry Krinock :
>
> I read somewhere that in some languages, for example Arabic, there are
> actually different forms for "one", "two", and "three or more".
Localizing plurals is hard because the plural rules for different
languages are complex. Just stay away from plurals if you can.
hat looks unprofessional and very un-Mac.
No, I'm not doing anything like that. Example:
Instead of "10 problems", use "Problems: 10".
Apple actually makes use of this strategy, thought only for certain languages.
For their English localization, they pretty much stick
Well, Ricky I see you're one of the few who has really thought through all the
issues.
On 2009 Dec 22, at 19:59, Kyle Sluder wrote:
> On Tue, Dec 22, 2009 at 11:54 AM, Ricky Sharp wrote:
>> * No plural forms (while allowing plurals can be handled, it's not worth the
>> effort IMO)
That's goo
existing automated-test infrastructure to do a full product
> walkthrough (setting up proper data along the way) and generating
> screen-shots. Such screen shots can now be viewed by the localization
> company's "QA" team to ensure all text is valid within its context.
>
gh (setting up proper data along the way) and generating screen-shots.
Such screen shots can now be viewed by the localization company's "QA" team to
ensure all text is valid within its context.
Furthermore, the "walkthrough" script will mine all text on the screen and lo
t your UI could use improvement if it is overly
textual. A good UI design can avoid localization being painful. This
is the true shortcut in localization
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or mod
On Dec 21, 2009, at 8:18 PM, Uli Kusterer wrote:
> On 20.12.2009, at 21:30, Ricky Sharp wrote:
>> Thus, I'm wondering if it would ultimately be worth it to externalize all
>> strings from my nibs and just put everything in my single .strings file.
>> This will clearly involve me adding tons of I
On 20.12.2009, at 21:30, Ricky Sharp wrote:
> Thus, I'm wondering if it would ultimately be worth it to externalize all
> strings from my nibs and just put everything in my single .strings file.
> This will clearly involve me adding tons of IBOutlet ivars just so that at
> runtime I can set the
On 2009 Dec 21, at 01:27, Symadept wrote:
> Now pass these files to Localization
> team and they shall simply copy paste the other version of the string in RHS
> of the corresponding files.
Well, of course there are tools for this. I use and recommend Max Seelemann's
Localizat
to change anyway and the dialog has to be
rethought somewhat. So all in all, specifically designing UI elements for each
locale make sense if you want the best results. It is also time consuming and
thus (probably) expensive.
It's weird to see big companies fall into localization blunders.
to set the string at runtime, as you
mentioned, with NSLocalizedString(@"Hello", nil). Now you generate various
language localizable.strings by Add Localization (mail me if you think you
need more info) from XCode and change the file format to UTF16. Now these
files shall still show you en
In getting quotes from many localization companies, I've found that some have
different processes. For example, one company would prefer if I just provide
.string files. During their QA process, they'll then run the app and look at
everything in context.
While generating .strings
/lv.lproj
enables opening Latvian localization correctly. Of course, this is a hack, that
cannot be used for "deployment", but still can be used to debug and test system
preference pane bundle written in X language while hoping that in the future
Apple will enable support for all languages
Filed report:
Enable localization for prefpane bundle used with the System Preferences app
Product: Mac OS X
Version/Build Number: 10C540
Classification: Feature (New)
Is It Reproducible?: Always
Summary:
When creating a preference pane bundle for System Preferences.app with
localizations for
On Nov 10, 2009, at 4:17 PM, MacProjects wrote:
> So You're saying... a no-go? Have to do everything programmatically? A bug or
> Apple just ignores the rest of the world ;) and solving this should be
> considered as "feedback for enhancement"?
It's not a bug; it's a missing feature. File a fe
Thanks for response!
That was exactly the first thing I tried before posting here. Didn't work =>
did not mention that.
I tried every possible name out there
• Latvian
• Latviešu
• lv
• lv_LV
+ for example, choosing "Latvian" or "lv" and opening that xib localization
On Nov 10, 2009, at 3:36 PM, Olivier Palliere wrote:
> First thing that comes to mind is that using English, French, German and so
> for your localized bundles is an old fashioned way that should not be done
> anymore. It does not support all languages. You must now use the iso code of
> the c
; NSLog(NSLocalizedStringFromTableInBundle(@"someword",nil,[NSBundle
> bundleForClass:[self class]],nil));
> }
>
> Using OS 10.6.2.
> The Latvian language is the first language set in System Preferences :
> Language & Text : "Drag languages into order yo
ingFromTableInBundle(@"someword",nil,[NSBundle
bundleForClass:[self class]],nil));
}
Using OS 10.6.2.
The Latvian language is the first language set in System Preferences : Language
& Text : "Drag languages into order you prefer" list, then comes English, then
Deutsch.
hello,
i have a project that is localized into multiple languages with the main
language being english. i did this in the pre-xib days where you could open
the nibs without xcode. in my project i only have english but i duplicated the
english nib into my other languages and everything actuall
Perfect! Thanks!
- Sebastian
On Mon, Jun 22, 2009 at 9:36 PM, Nick Zitzmann wrote:
>
> On Jun 22, 2009, at 7:56 PM, Sebastian Celis wrote:
>
>> I have a strings file defined for my Core Data model. As such, my
>> Data.xcdatamodel file has a corresponding DataModel.strings file. This
>> seems to
On Jun 22, 2009, at 7:56 PM, Sebastian Celis wrote:
I have a strings file defined for my Core Data model. As such, my
Data.xcdatamodel file has a corresponding DataModel.strings file. This
seems to work great for auto-generated messages, but now I have a need
to access these localized strings p
Hello,
I have a strings file defined for my Core Data model. As such, my
Data.xcdatamodel file has a corresponding DataModel.strings file. This
seems to work great for auto-generated messages, but now I have a need
to access these localized strings programmatically. NSLocalizedString
does not seem
On Wed, Apr 8, 2009 at 7:46 AM, Graham Cox wrote:
>
> On 08/04/2009, at 2:45 PM, Graham Cox wrote:
>
>> Thanks for all your help - just remains to be seen now if certain users
>> can now open my app! ;)
>
> It occurs to me that there is another potential problem that I've
> overlooked. System loca
You can always specify the specific locale to use in a custom sorting
method.
Sent from my iPhone
On Apr 8, 2009, at 6:46 AM, Graham Cox wrote:
On 08/04/2009, at 2:45 PM, Graham Cox wrote:
Thanks for all your help - just remains to be seen now if certain
users can now open my app! ;)
On 08/04/2009, at 2:45 PM, Graham Cox wrote:
Thanks for all your help - just remains to be seen now if certain
users can now open my app! ;)
It occurs to me that there is another potential problem that I've
overlooked. System locale affects sorting, right? At least the comment
in the S
On 08/04/2009, at 2:31 PM, Michael Ash wrote:
I got curious and experimented. Archiving (as in NSCoder) appears to
work fine, but if you send an NSDate through an XML plist, it loses
its fractional seconds! (rdar://6768646) So if you're using plist
serialization, you may well not get the same d
On Wed, Apr 8, 2009 at 12:11 AM, Graham Cox wrote:
> Well, the date itself is stored in the archive using standard archiving. I'm
> not sure how it writes itself - so should I be worried? I thought I could
> rely on archiving/dearchiving accurately giving me back whatever I stored
> though in this
On 08/04/2009, at 1:54 PM, Michael Ash wrote:
If this is also how you store your dates then this is fine. If you
store them in some other way (e.g. asking the system to put them in an
plist) then this is still fine as long as you're using whole numbers
of seconds. If you can store arbitrary fra
On Tue, Apr 7, 2009 at 7:57 PM, Graham Cox wrote:
> I'm doing this, which is the first step in building an NSData representation
> of the various objects, prior to SHA-1 digesting the result. Be good to know
> if this is adequate for system/architecture independence. The intention is
> that the di
1 - 100 of 147 matches
Mail list logo
