My application have Arabic and English languages enabled. When the url is generated for news items, the date component is present in the URL and its different for each language. Gregorian date for English translation and Hijri date components for arabic item's url.
The requirement here is to have same date (Gregorian) in both items url, is there any fix or options available to change this?
Thanks
Salam
That's not gonna be easy, because when the Thread is in AR culture, then calling date.ToString("yyyy/MM/dd") returns something completely different compared to when the Thread is in EN culture, as you correctly pointed out.
What Sitefinity allows you to do, is to change the urlformat of the news items, so the easiest way would be to remove the PublicationDate from the url format altogether. As a result the news url will not have a date portion.
If that's acceptable for you, then check how to do it here:
https://www.progress.com/documentation/sitefinity-cms/for-developers-change-url-format-for-built-in-modules-with-single-content-type
Simply create this urlFormat parameter and set its value to
/[UrlName]
Related
I need to create a PDF with a date field that displays dates in the format dd.mm.yyyy. This field must be validated and should also accept inputs in other formats.
For example, users should be able to input dates in the form dd.mm.yy, which will then be expanded to dd.mm.20yy (MS Office apps like Excel do this).
Alternatively, selecting multiple valid formats would be an acceptable solution.
What currently happens:
If the date format of the field is set to dd.mm.yyyy, dd.mm.yy is rejected.
If the date format of the field is set to dd.mm.yy, dd.mm.yyyy is accepted (but formatted to dd.mm.yy).
The last behaviour is almost what i need, just with the wrong format.
Is there a way to do this without custom Javascript? If not, is there a way to still use the built-in formatting or do i have to rewrite everything in JS?
Unfortunately this is not achievable with Acrobat's built-in formatting.
One thing to add to your second bullet point: it trims the date down to .yy when you exit the field, but it still retains all four digits. When you click into the field, it will revert back to being .yyyy. That may or may not matter depending on how you're using it.
Regarding a custom validation, a quick Google search will yield an abundance of Javascript date validation scripts. Something like this could probably be quickly repurposed for your application.
Recently,I am handling a solution for WebPart internationalization,but I am not familiar with the culture or habits in different regions.So I am asking for some information if you are glad to help.
Suppose I am a different person in another region,for example,a German.I am using the SharePoint,which is a German edition.So,
1) What's the input habit of me?
For example,if I need to input "10000",will I input "10.000,00" or just "10000"?Which is frequent to the user?
2) How to handle the "Date" and "Time" format?
I think it's better if I can select the date or time instead of inputing the date or time string.
3) Any information that you think will be helpful to me?
That is very kind of you,thanks for your help!
To be honest, I am not sure how you want to handle i18n, but I am assuming that you want to do this on the client side.
In this case, I can recommend using Globalize for formatting (both numerical values and date/time could be handled this way).
As for parsing dates (that is handling dates provided by user), there is actually even easier way - just use jQuery UI Datepicker with valid regional script. Obtaining Date object is as easy as calling Datepicker's getDate method.
I am having a problem with an MVC3 application using a jQuery UI DatePicker object.
Within the MVC application, I ask the user to pick their required culture, i.e en-GB, which then formats all dates and currencies in the application in the british format.
I can then access the formatter code for this via Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern
However, the format returned for UK dates is: dd/MM/yyyy
To format the resulting data from the jQuery UI datepicker, I need to specify a date format. But for UK format dates, I need to specify the format as dd/mm/yy
The simple solution would be to just use Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern in my jQuery calls to format the date, but obviously this gives a formatting inconsistency as this is interpreted differently by jQuery UI (01/December/20112011 instead of 01/12/2011)
Is there any easy way around this?
The only way I can think of doing it is asking the user twice what format to display dates in?
I could think of another solution, but that's pretty low-tech, I'm not sure if that is the right way to do it:
var dateTime = Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern;
var lowerCaseMonths = Regex.Replace(dateTime, "MM","mm");
var yearOnlyOnce = Regex.Replace(lowerCaseMonths, "yyyy", "yy");
Without "explaining variables" just
Regex.Replace(Regex.Replace(Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern, "MM","mm"), "yyyy", "yy")
Then I guess no matter in what format it is, dd/MM/yyyy MM/DD/yyyy dd-MM-yyyy etc, it should work out in jQuery.
Maybe someone has a better solution, but at least this seems better than asking for user input twice.
#System.Threading.Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern.ToLower().Replace("yyyy", "yy")
I already know how to localize an ASP.NET MVC3 URL (using this technique).
This solution is very elegant and i already managed to tweak it to my needs.
But now i have this small (or rather huge) problem:
how is it possible to have localized url query parameters?
For example how is it possible to have this (US) english version
english URL: http://www.mysite.com/en-US/Classifieds/Search?ZipCode=92274
german (DE) version:
http://www.mysite.com/de-DE/Anzeigen/Suche?Postleitzahl=71710
spanish (ES) vesrion:
http://www.mysite.com/es-ES/Clasificados/Busqueda?Codigo_postal=08110
See the bolded part? This is what i'm looking for!
Thanks in advance
PS. I need this cause i think this will give much better SEO rankings. Is there anyone who can confirm this?
I can think of several ways of doing what you need. You may want to try to create your own HTML helper for localized links building. That could include the translation logic based on db table ( baseName, Culture, translation ). Once you've got this in place you either could refer to Request object and get the parameter by index, or create a logic to translate back ( again based on your table) to the base name.
Regarding your SEO question - I only know that MVC rewriting logic and 'friendliness' of the links is based on the fact that static-looking links are crawled faster then the dynamic ones. So that's something to consider on your site.( http://www.seo-consultant-services.co.uk/static-html-vs-dynamic-urls.html) I'm not an expert but I would guess that translating your url parameters makes sense if you expect users to search for services like this for example ' near ZipCode 92274' (I may be wrong)
I want to make a multi-language site, such that all or almost all pages will be available in 2 or more translations. What are the best practices to follow?
For example, I consider these language selection mechanisms:
Cookie-based selection of the preferred language.
Based on Accept-Language header if the cookie is not set.
Based on GeoIP otherwise (probably).
Is there anything else?
How should different translations be served?
as LANG.example.com/page
as example.com/LANG/page
as example.com/page?hl=LANG
...
any of the above with a redirect to example.com/page? (It seems to be discouraged)
How to ensure that all the translations are properly indexed?
Sitemaps with all pages + correct Content-Language header are enough?
What is the best way to let the users know there are other translations, but do not distract them?
list available languages in the header/footer/sidebar (like Wikipedia)
put “Choose a language” selector next to the content
What is the best policy to deal with missing/outdated translations?
do not display missing pages at all or display a page in a different language?
display old translation, old translation with a warning or a page in a different language?
What else should I take into account? What should I do and what I definitely should not?
In addition to #Quassnoi's answers ensure that you standard RFC 4646 language identifiers (e.g. EN-US, DE-AT); you may already be aware of this. The CLDR project is an excellent repository of internationalization data (the Supplemental Data is really useful).
If a translation of a specific page is not available, use a language fallback mechanism back to the neutral language; for example "DE-AT", "DE", "" (neutral, e.g. "EN").
Most recent browsers and the underlying operating systems will correctly show all of the characters required for a locale selector list if the page is encoded correctly (I'd recommend all pages being UTF-8). Ensure that the locale list contains both the native and current-language names to allow both native and non-native speakers to view the specified translations, e.g. "Deutsch (German)" if the current locale is EN-*.
A lot of sites use a flag icon to show the current locale, but this is more relevant to the location and some people may be offended if you show only a dominant flag (e.g. the US or UK flag for English).
It may be worthwhile to have a more visible (semi-graphical) locale selector on the home page if no locale cookie has been submitted, using a combination of GeoIP and Accept-Language to determine the default locale choice.
Semi-related: if your users are in located in different time zones include a zone preference in their account profile for displaying time values in their local time. And store all time stamps using UTC.
Make the decision whether you need support for languages that require double byte characters early on (Chinese, Japanese, Korean, etc), Unicode is the preferable choice. It can be tedious to change later, especially if you have a database that doesn't use unicode.
Cookie-based selection of the
preferred language.
Based on Accept-Language header if
the cookie is not set.
These two you should support.
Put a big english banner at the top of your page that reads This page in English.
as example.com/LANG/page
This is the best choice.
LANG.example.com isn't good for autocomplete, and the question marks look ugly.
list available languages in the header/footer/sidebar (like Wikipedia)
Choose a language dropbox is confusing, as it is not intelligible being written in a wrong foreign language and spoils overall impression being written in English.
And you always tend to make the error selecting the language you don't even have fonts for leaving yourself on a page full of question marks.
display old translation with a warning
You know there is something you can read and get the point, but for the details you'd better get a dictionary and read it in English.