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
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
>
he 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 support Base
ovec 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?
>>>
>>> —
> 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 localizat
> 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.lproj for locali
he 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 support Base
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
'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, and autolayo
ve 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?
>
> —Rob
>
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 much cleaner
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
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 bap...@my.fsu.edu wrote:
I am getting an error in iTunes Connect for my App
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 localized anymore
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
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 an
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
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, Arun
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 ddavi...@apple.com wrote:
The localization used is determined by matching the AppleLanguages list
against
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
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
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
On 2 Feb 2013, at 10:39, Arun arun...@gmail.com 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
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 gets
Even that does not work either.
On Sat, Feb 2, 2013 at 7:46 PM, Keith Duncan ke...@33software.com wrote:
On 2 Feb 2013, at 10:39, Arun arun...@gmail.com 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
On Feb 2, 2013, at 7:25 AM, Arun arun...@gmail.com 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
Yes. I used underscores. The project directories are also correctly named
On Feb 2, 2013 10:44 PM, Kyle Sluder k...@ksluder.com wrote:
On Feb 2, 2013, at 7:25 AM, Arun arun...@gmail.com wrote:
Hi All
I have a sample cocoa application which i am trying to localize in 3
flavors.
1.
On 2 Feb 2013, at 15:26, Arun arun...@gmail.com 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)
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 you
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 ke...@33software.com wrote:
1. en-US
2. en-UK
3. en
There is no en-UK locale ID, nor
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
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
localization) a
InfoPlist.strings containing (at a minimum)
HPDBookTitle = YOUR LOCALIZED HELP TITLE;
Without this, you'll always get the development language.
Regards
Markus
--
__
Markus Spoettl
___
Cocoa-dev
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 localization)
a InfoPlist.strings containing (at a minimum
Am 17.08.2012 um 18:59 schrieb Kelly Keenan kkee...@apple.com:
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
(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.
In the info for one of my
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
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
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,
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
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
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 agree
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
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.
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://www.icalamus.net/ioda
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 the table name and key
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 or
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 localized
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 absolutely need to provide context
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
) that it 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
en.lproj
and Text → Language):
British English,
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
de
fr
en
it's development language (Localization
not find an authoritative answer) that it 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
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
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 in
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
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/Internationalization/
it mentions
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/Internationalization
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 load the
english nibs?
Just read http
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
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 of them works except
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 Localizable.strings. When
On Jan 27, 2010 7:51am, Steve Bird sb...@culverson.com 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've
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 you do not have key
...@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 you do not have key =something = something else;
- Check
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 rsh...@mac.com wrote:
* No plural forms (while allowing plurals can be handled, it's not worth the
effort IMO)
:
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 with the plural forms.
But, for languages such as Russian, they use the colon approach. I didn't
want to have two
2009/12/23 Jerry Krinock je...@ieee.org:
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
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 rsh...@mac.com wrote:
* No plural forms (while allowing
) 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 look
for curly braces. That will mean that either an outlet isn't connected
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
look for curly braces
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 english. Now pass these files
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. Pixar's
Wall.E
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
Localization Suite, and just
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 their
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
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 moderator comments to the list.
Contact
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 from nibs
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. However firing up preference pane opens English localization nib and
NSLog writes English word. If I change list and order
:
Language Text : Drag languages into order you prefer list, then comes
English, then Deutsch. However firing up preference pane opens English
localization nib and NSLog writes English word. If I change list and order
Deutsch as the second language, then it fires up. Thus - Latvian in the first
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
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
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 in
IB gives me the correct
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
/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 available
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
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
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
Perfect! Thanks!
- Sebastian
On Mon, Jun 22, 2009 at 9:36 PM, Nick Zitzmannn...@chronosnet.com 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
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
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 graham@bigpond.com 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
On Wed, Apr 8, 2009 at 7:46 AM, Graham Cox graham@bigpond.com 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
data, is digitally signed with a SHA-1
hash, which in turn is based on the object's -hash method. As far as
I could tell, the -hash method returns a value that is sensitive to
the actual stored date, but not to the date localization on the
system.
At runtime, the date is recovered
On 08/04/2009, at 4:18 AM, Christopher Kane wrote:
Now that everybody else has had their say, I'll throw in my two
bits: ;-)
* as others have pointed out, never store the hash of an object or
data computed from the hash, nor transmit the hash of an object
outside a process, if your goal
On Tue, Apr 7, 2009 at 7:57 PM, Graham Cox graham@bigpond.com 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
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
1 - 100 of 144 matches
Mail list logo
