Is there an international (or widely used) standard code to specify the names of calendar systems?
I'm working on an application that (among other things) stores and presents historical dates in multiple calendar systems, such as Gregorian, Jewish, Hijri, and others. When storing the date, I need to be able to say what calendar system it is in.
I could invent my own system, but is there something already out there, similar to ISO 639 for languages? I haven't been able to find anything after quite a long search, but maybe I've been using the wrong terms.
Valid question; it is always better not to use arbitrary codes for such things.
You can simply use the values of name attribute which CLDR uses:
<key name="ca" description="Calendar algorithm key" alias="calendar">
<type name="buddhist" description="Thai Buddhist calendar"/>
<type name="chinese" description="Traditional Chinese calendar"/>
<type name="coptic" description="Coptic calendar"/>
...
<type name="islamicc" description="Civil (algorithmic) Arabic calendar" deprecated="true" preferred="islamic-civil" alias="islamic-civil"/>
</key>
But you can also, adapt the method that was used in CLDR data definition which consisted of using an extension to BCP47 ("Tags for Identifying Languages") called RFC6067 for "identifying Unicode locale-based variations using language tags. The 'singleton' identifier for this extension is 'u'". For example, the language Thai is identified by th. Therefore, th-u-ca-buddhist identifies the locale as Thai with support for Buddhist calendar:
th-u-ca-buddhist
| | |
| | +--> Calendar name (values in CLDR bcp47/calendar.xml).
| +-----> 2 char key defining extension to follow (here "ca" for calendar).
+--------> Identifies that extension U values are to follow.
Few more extended usage examples:
fa-u-ca-islamic-rgsa: Farsi with Islamic calendar, Saudi Arabia sighting.
fa-u-ca-persian: Farsi with Persian calendar.
fa_AF-u-ca-persian: Farsi (Afghanistan) with Persian calendar.
Obviously, if your intention is just to store the date and identifier for the calendar it is in, you can use en; i.e.
{ 'year': 1392, 'month': 6 , 'day': 31 , 'calendar': 'en-u-ca-persian' }
Related
I want that Orbeon validate these two formats when I insert in date input field date like this "12/11/2016" or "12 11 2016".
I try to insert two properties in properties-local.xml. Orbeon accepts two formats but not totally when I insert 12 11 2016, it accepted but when I type "12l 11 2016" an error shows. The problem that when I correct the error Orbeon still doesn't accept this date "12 11 2016" and when I type "12/11/2016" the date is accepted and the error is removed.
<property
as="xs:string"
name="oxf.xforms.format.input.date"
value="[D][M][Y]"/>
<property
as="xs:string"
name="oxf.xforms.format.input.date"
value="[D]/[M]/[Y]"/>
Only a few formats are supported as per the documentation:
[M]/[D]/[Y] e.g. 11/5/2008 (also called "North America format")
[D]/[M]/[Y] e.g. 5/ 11/2008 (also called "European format")
As a variation, you can use another separator such as a dot (e.g. [D].[M].[Y]) or dash ([D]-[M]-[Y])
As a variation, you can write [M01] and [D01] if you want day and months on one digit to be prefixed with a 0, e.g. 11/05/2008
So your format, [D][M][Y], won't work. It is not possible right now to support this format without making changes to the Orbeon Forms implementation.
When I type:
Yii::app()->getLocale()->dateFormat
it gives me the correct dateformat for the current set language. (in my example it is 'de' => dd.MM.yyyy). But when I type:
Yii::app()->format->dateFormat
Yii gives me the date format for 'en_us' (Y/m/d).
With getLocale() I will get only the string saved in i18n file. In ->format->date() this format string should be used, but I don't find a way to assign the i18n string to the CDateFormatter or CFormatter Object.
The CFormatter component accessed with Yii::app()->format is not meant to be used for localization out of the box; it does not automatically work according to the application locale.
You could manually change the relevant properties on Yii::app()->format to bring it in line with the application locale, but there is a more convenient way to format dates:
Yii::app()->locale->dateFormatter->formatDateTime(...)
See CDateFormatter::formatDateTime for more information; if you want more control, there are other methods such as CDateFormatter::format available. Also keep in mind that CLocale::getNumberFormatter() is available to format numbers.
I am trying to find the best route to get in some Custom formats I need. For example if I have a phone number 0803456765
In India it may be represented as +91 (080) 3456765
In US it may be 080-345-6765 and so on
I could keep the format in the properties file and based on locale I could pull the format and format the String. I could also have a Util class which does this for me after I identify the Locale.
But I think there might be a better route using NumberFormat. I guess NumberFormat automatically figures out the Locale and applies a certain Pattern to the String. Can I customize this pattern ? In the sense, can I tell GWT to use my Custom pattern for the US Locale
I know we can do this
// Custom format
value = 12345.6789;
formatted = NumberFormat.getFormat("000000.000000").format(value);
// prints 012345.678900 in the default locale
GWT.log("Formatted string is" + formatted, null);
but I don't want to specify my formatting pattern as in 'NumberFormat.getFormat("000000.000000")'. I want to override the default number formats of various Locales in GWT to achieve this. How do I do this ?
Don't roll your own. Google open sourced their library which you can leverage. It supports
Parsing/formatting/validating phone numbers for all countries/regions
of the world.
i have a very simple vevent "every Monday 9 to 5" and some time periods where this event doesn't take place. like 7.8.2011 to 24.10.2011. What is the best way to represent this in iCalendar?
a lot of EXDATEs? special EXRULEs?
Oh dear,
Exrule is deprecated now in RFC 5545, so best skip that one (although that would be neatest and most ics s/w probably still copes with it (like mine :), for compatibility )
EXDATES are valid, but gosh that would be cumbersome if you mean the whole period from 7 August to 24 October, you'd have to enter every week day
You possibly have to just create two events - although one could 'relate' them.
I have not tried it yet, have been thinking about if for a different reason, but there is the concept of 'RELATED-TO' with modifer RELTYPE (PARENT, SIBLING etc)
RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713#
example.com
Property Name: RELATED-TO
Purpose: This property is used to represent a relationship or
reference between one calendar component and another.
Value Type: TEXT
Property Parameters: IANA, non-standard, and relationship type
property parameters can be specified on this property.
Conformance: This property can be specified in the "VEVENT",
"VTODO", and "VJOURNAL" calendar components.
Description: The property value consists of the persistent, globally
unique identifier of another calendar component. This value would
be represented in a calendar component by the "UID" property.
I am localizing my app for Denmark. I have the Localizable.Strings and the XIBs translated into Danish.
On iPhone a user can
Set the 'Region Format' to 'Denmark'
but keep the language 'English'
Set the 'Region Format' to any English-speaking country but keep
the language 'Dansk'
Set the 'Region Format' to 'Denmark' and language 'Dansk'
My question is: for any of the above settings should the app show the 'Danish' version (which for my App will mean all text in UI and the database to be in Danish.) or should the 'Danish' version only come when user sets the language to 'Dansk'?
This is a great question.
The real issue it comes down to is, in Apple's opinion, as they did it, does NSLocalizedString tend to favour the 'Region Format' or the 'language' setting?
I have never been able to find a clear answer on this, I just let NSLocalizedString decide.
(Purely FWIW, I think follow the "language" setting.)
It's possible the following code snippets could help you.
// to ("usually") get the preferred language FROM THE SET WHICH we supplied in bundle
// [[[NSBundle mainBundle] preferredLocalizations] objectAtIndex:0]
// to ("often") get the preferred language REGARDLESS OF what we supplied
// [ [NSBundle preferredLocalizationsFromArray:[NSLocale ISOCountryCodes]] objectAtIndex:0]
// to ("fairly reliably") get the user's chosen language setting...
// [ [NSLocale preferredLanguages] objectAtIndex:0]
It may not help, but I hope it helps.
Languages and locales are treated differently by Cocoa, because they are independent concepts. NSLocalizedString() will obey the current language setting of the OS, where things like dates, times, and numbers are affected by the locale setting.
Why locales are handled separately from languages can be found in the Locales Programming Guide:
When you display data to a user it
should be formatted according to the
conventions of the user’s native
country, region, or culture.
Conversely, when users enter data,
they may do so according to their own
customs or preferences. Locale objects
are used to provide information
required to localize the presentation
or interpretation of data. This
information can include decimal
separators, date formats, and units of
measurement, as well as language and
region information.
For example, by convention in the
United States “7/4/76” represents the
Bicentennial of the Declaration of
Independence. However, in Great
Britain, it represents the “7th of
April, 1976”; in Thailand using the
Thai Traditional Calendar it might
represent “April 7th, 2519”; and in
France it represents “7 avril 1976”.
To take a more subtle example, in the
United States“12.125” represents the
decimal number twelve and one eighth,
whereas in Germany it represents
twelve thousand one hundred and
twenty-five.
In the example given there, you might have a user who prefers to use English as their primary language, yet who lives in Germany and is used to a comma as a decimal separator, not a period.
The Internationalization Programming Topics guide has a lengthy discussion of all the issues involved and how to deal with them.