I noted that some apps change date-time formatting with the locale changing and not with the language changing, but also viceversa.
What is the suggested way to localize date-time? According locale or language?
Fran
Locale is any combination of 3 things: country, language and a variant. There are well-known combinations of these 3 but you can mix and match these to make your own combination.
Now coming to your question, properly handling the date and time involves Locale, TimeZone and the date format. checkout this great presentation on i18n
In general you assume that the locale defines the presentation.
However, you can provide language specific choices for non-native speakers that essentially set their locale behind the scenes.
For example:
User A speaks French and lives in UK - Locale is UK, but user prefs say Locale is France
User B speaks English and lives in USA - Locale is USA, and user prefs default to American English.
That should satisfy most requirements.
Related
I'm trying to validate an rss feed and I get an error saying "pubDate must be an RFC-822 date-time".
The date is in Turkish Sal, 07 Nis 2020 00:05:11 +0000.
If switched to English it validates. But it's a Turkish site...
I haven't been able to find any documentation saying RFC-822 is English only, but nothing with language information either.
It's intended for consumption by computers more than humans, but the tokens used in RFC-822 do correspond to English month and day names.
I try to get incidents from a route and as shown we are using es-ES language, but the text of the incidents does not arrive translated, is it possible to translate them?
You can specify the language for your textual information by providing language as parameter and you can choose any language from the below list -
https://route.api.here.com/routing/7.2/calculateroute.json?app_id=XXXapp_code=YYY&waypoint0=geo!52.5,13.4&waypoint1=geo!52.5,13.45&mode=fastest;car;traffic:disabled&language=es-es&departure=now&routeAttributes=incidents
https://developer.here.com/documentation/routing/topics/resource-param-type-languages.html#languages
So i need to see how much sessions is made by certain organic keyword, also by each language. The problem is that there is many variations of language codes, for example: en and en-us so all my keywords are split.
There is certan number of sessions for keyword A for en
And there is also certain number of session for keyford A for en-us
Example of keyword sessions being split couse of language code: http://prntscr.com/483p1i
How do i show traffic from both variation of language code so it is not split in 2?
The same problem is also for other languages. How can i get the report that i need? I tried in Acquisition > Keywords > Organic and also Audience > Geo > Language, but i always get stuck with multiple language codes for same languages.
Set language as second dimension, choose advancend filter, select language as dimension to filter by and select "contains" as condition (you could also use regular expressions, but this is the simple option). Then "en" will give you en-us, en-gb and other combinations.
The first line in the resulting data table will give you the totals for the chosen language.
Google Analytics displays statistics depending on user's language.
I have visitors whose locale is en-us (english), fr (french), but also c.
What does this c language code stands for ?
I took a look at reference tables here and here but could not find c.
Thanks in advance !
The only locale names you can count on finding on all operating systems are these three standard ones:
"C"
This is the standard C locale. The attributes and behavior it provides are specified in the ISO C standard. When your program starts up, it initially uses this locale by default.
"POSIX"
This is the standard POSIX locale. Currently, it is an alias for the standard C locale.
""
The empty name says to select a locale based on environment variables. See Locale Categories.
In my case, that was bots.
The network domain was either kimsufi, amazonaws, or not set ....
Always the same pages viewed, and always direct trafic.
If I were you, I would check these other dimensions.
Language codes are sent by the client, to the server, so that the server may return specific page information based upon this (such as translated pages). It seems though, that Google Analytics may not check for validity of these language codes before adding them to your charts.
For example, I have at least one language codes in the form *30789a483078979530789a5830789a2c307898a4 visible in my data.
Further analysis of the few of c language-code visitors visible in the information from my website, it appears that they all originate from Linux OS (or undefined), and all use Safari or are part of a script getting data from a webpage (one in particular was http://pagepeeker.com )
Despite the language, the requests originate from all over the world.
In summary, I think it's just invalid data that's being sent to GA, and should probably be ignored.
What's the recommended timestamp format for a REST GET API like this:
http://api.example.com/start_date/{timestamp}
I think the actual date format should be ISO 8601 format, such as YYYY-MM-DDThh:mm:ssZ for UTC time.
Should we use the ISO 8601 version without hyphens and colons, such as:
http://api.example.com/start_date/YYYYMMDDThhmmssZ
or should we encode the ISO 8601 format, using for example base64 encoding?
Check this article for the 5 laws of API dates and times HERE:
Law #1: Use ISO-8601 for your dates
Law #2: Accept any timezone
Law #3: Store it in UTC
Law #4: Return it in UTC
Law #5: Don’t use time if you don’t need it
More info in the docs.
REST doesn't have a recommended date format. Really it boils down to what works best for your end user and your system. Personally, I would want to stick to a standard like you have for ISO 8601 (url encoded).
If not having ugly URI is a concern (e.g. not including the url encoded version of :, -, in you URI) and (human) addressability is not as important, you could also consider epoch time (e.g. http://example.com/start/1331162374). The URL looks a little cleaner, but you certainly lose readability.
The /2012/03/07 is another format you see a lot. You could expand upon that I suppose. If you go this route, just make sure you're either always in GMT time (and make that clear in your documentation) or you might also want to include some sort of timezone indicator.
Ultimately it boils down to what works for your API and your end user. Your API should work for you, not you for it ;-).
Every datetime field in input/output needs to be in UNIX/epoch format. This avoids the confusion between developers across different sides of the API.
Pros:
Epoch format does not have a timezone.
Epoch has a single format (Unix time is a single signed number).
Epoch time is not effected by daylight saving.
Most of the Backend frameworks and all native ios/android APIs support epoch conversion.
Local time conversion part can be done entirely in application side depends on the timezone setting of user's device/browser.
Cons:
Extra processing for converting to UTC for storing in UTC format in the database.
Readability of input/output.
Readability of GET URLs.
Notes:
Timezones are a presentation-layer problem! Most of your code shouldn't be dealing with timezones or local time, it should be passing Unix time around.
If you want to store a humanly-readable time (e.g. logs), consider storing it along with Unix time, not instead of Unix time.
RFC6690 - Constrained RESTful Environments (CoRE) Link Format Does not explicitly state what Date format should be however in section 2. Link Format it points to RFC 3986. This implies that recommendation for date type in RFC 3986 should be used.
Basically RFC 3339 Date and Time on the Internet is the document to look at that says:
date and time format for use in Internet protocols that is a
profile of the ISO 8601 standard for representation of dates and
times using the Gregorian calendar.
what this boils down to : YYYY-MM-ddTHH:mm:ss.ss±hh:mm
(e.g 1937-01-01T12:00:27.87+00:20)
Is the safest bet.
Always use UTC:
For example I have a schedule component that takes in one parameter DATETIME.
When I call this using a GET verb I use the following format where my incoming parameter name is scheduleDate.
Example:
https://localhost/api/getScheduleForDate?scheduleDate=2003-11-21T01:11:11Z
For JavaScript,
I normally save date as ISO format by writing: new Date().toISOString();.
Hopefully, it helps with your project.