How do I change the date format in the header when printing with DotNetBrowser? - chromium

The only localisation I could find is described here:
https://dotnetbrowser.support.teamdev.com/support/solutions/articles/9000110018-chromium-language-localization
DotNetBrowser allows configuring Chromium engine with specified
language (two letter code from ISO-639 e.g. "en", "de", "it", etc).
The language will be used for UI text messages localization (e.g. text
on the web page that's displayed when Chromium failed to load URL).
By default, Chromium engine is configured to use .NET application
language that can be received from
theCultureInfo.CurrentUICulture.Name property. To configure Chromium
engine with .NET application language, DotNetBrowser extracts the
language from theCultureInfo.CurrentUICulture.Name property and passes
it to Chromium engine via the --lang Chromium switcher.
If you need to change this default behavior, then you can configure
Chromium engine directly with specified language via Chromium--lang
switcher.
Unfortunately this does not seem to apply any date formatting (which makes sense as it only seems to pay attention to the language "en" and not the locale)
When I print, the header on every page has a date which is in US format. My customers are not in the US and giving them dates in US formats would be a disaster.
Is there any way to set the date format in DotNetBrowser / Chromium?
In Chrome Advanced Settings I can pick English New Zealand and English UK as languages and those settings do affect the printed page headers.

You could specify English UK locale as "en-GB" as shown below:
BrowserPreferences.SetChromiumSwitches("--lang=en-GB");
Do not forget that this switcher should be set before you create any Browser instance.
This article describes how to set Chromium switchers: https://sites.google.com/a/teamdev.com/dotnetbrowser-support/documentation/chromium-switches

Related

The Macedonian (mk) language is not taken the translations given in template setup in TYPO3

I am using Typo3 version 9.5.13 with 16 languages, there is a language 'Macedonian(mk)' and I have added a translation for this language with a key in Typo3 template setup, but it's not taking this translation and shows the default translation. This language is not in the Typo3 Supported languages list.
Thank you
In order for TYPO3 to support "mk" locale (and thus, XLF-based label files with "mk.locallang.xlf") one needs to add this line to typo3conf/AdditionalConfiguration.php
$GLOBALS['TYPO3_CONF_VARS']['SYS']['localization']['locales']['user']['mk'] = 'Macedonian';
This is the beginning to make it even possible to allow mk for TYPO3 Backend and Frontend - related to label files (XLF).
The other parts (creating a sys_language record, adding an icon, adding "mk" to the site language etc) are still valid and need to be done as well, in order to determine "mk" in a multi-language setup for TYPO3 Frontend.
Add the language to typo3/sysext/core/Configuration/TCA/sys_language.php
Insert the translation of the language to typo3/sysext/core/Resources/Private/Language/db.xlf
Add the locale to typo3/sysext/core/Classes/Localization/Locales.php
Add the flag icon to the IconRegistry: typo3/sysext/core/Classes/Imaging/IconRegistry.php
Add the icon identifier to typo3/sysext/backend/Configuration/SiteConfiguration/site_language.php
You can see an example for Maori here:
https://github.com/TYPO3/TYPO3.CMS/commit/a8c16c45f8a1fce1d858815cef6c1ad83cff5d76

How to geotarget website with multiple languages but one link only?

I have a website with two languages, which works in this format:
example.com/changelanguage.xx?lang=de
and redirects to German language
and calling the same URL again like:
example.com/changelanguage.xx?lang=​en
redirects to English language.
The URL remains the same example.com after redirection, just the language changes.
How to add the hreflang attribute here (for Google indexing)?
It’s a bad practice to use the same URL for different (i.e., translated) content.
Consumers, like search engine bots, would use rel-alternate + hreflang markup to find translations. For this to work, you have to provide a different URL for the translated page.
From the perspective of the search engine, it doesn’t work for their users if using the same URL: when they give http://example.com/foobar as search result, they want to make sure that their users get the language the search engine intended (e.g., someone searching for German terms should get the German page). But with your system, this doesn’t work; the search engine user might end up with the English version.
Instead, you should represent the language in the URL, e.g. the language code as first path segment:
http://example.com/en/contact
http://example.com/de/kontact
(Or use different domains/subdomains, or add a query parameter, etc. If you can make sure that translated pages would never have the same URL slug, you could even omit the language codes.)
This is a year late but https://www.bablic.com/ do exactly this!
Furthermore they can automatically detect the language set in the user's browser and automatically show the user your website in that language!

How can I change language and locale of only my application programmatically

I want to change language and locale of my application alone to a language different than user's default that is set on the system. Say my application should use resources of french even though the system default is set to English.
I found few examples for iOS (How to force NSLocalizedString to use a specific language) but even this is only for language, but nothing for OSX. I have the french resource in my bundle. I just want to override the defaults for my application alone. Without changing the entire OS locale from system preferences.
There are nice apps for this problem: Language Switcher and App Language Chooser to name a few.
To do it programmatically, you can use the defaults command to change the app's AppleLanguages property to (fr) or (en, ko), as the following shell script:
bundleId=BUNDLE_ID_OF_YOUR_APP # such as, com.apple.Finder
# change AppleLanguages
defaults write $bundleId AppleLanguages "(fr)"
# open your app
open -b $bundleId
# then restore the language
defaults delete $bundleId AppleLanguages
See the answer to this similar question at superuser for more detail: Can I change the default language of a application / program in Snow Leopard?.

Localization of a DotNetNuke website

I am working on a website in dnn. I want to change the language of website or particular page. So I download the language package for spanish(es-es),chinese(zh-cn) and install them from host. Next when I changed the language of browser then the website language didn't change. Working on dnn 5.0.
Please let me know how I can use language packages in dnn website.
For initial translations and maintenance of DotNetNuke translations, I recommend the use of OmegaT. It handles resx files directly. And content (such as HTML or Blogs) can be downloaded, translated and then uploaded thanks to the APIs of DNN (drop me a note if you need the scripts).
OmegaT stores the translations in it's memory (a TMX file, which is actually some kind of XML). It also uses Google Translate and similars, and has a fast user interface which increases translation speed a lot when compared against continously waiting for DotNetNuke to handle your updated resources.
More info on OmegaT. An example of a translated site and modules: site translated from Dutch into English
You should probably ask this in the DotNetNuke forums: http://www.dotnetnuke.com/tabid/795/default.aspx.
There's one dedicated forum for questions about language packs and localization. You will probably find your answer there: http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/77/scope/threads/Default.aspx
The language packs don't always have translations for everything on the site, especially content that you added yourself. You'll need to do two things to get them working properly:
Go to Admin > Languages, and enable the languages you want to use.
Open the Language Editor and start translating. Under each resource name, you will see an edit text box for the localized value, and a read-only text box for the default value. In most cases, you'll need to translate verbatim what you see under "default value".
We had to write our own menu provider to get the menu to do this - instead of going for the resource files we went for a database solution - other reasons applied to this as well - we also built an interface for doing this - as for things like the text/html module there are some third party builds that allow you to nationalize content. Apollo comes to mind Apollo Software they have some multilanguage modules
The language packs will typically only localize text used by the core such as "Login" and "Settings". It is designed so that you can have a site in a language other than English, not so you can have multiple languages on one site. You can easily have multiple portals, each with a different language.
In order to have multiple locales on one portal you will need to use a third party module or develop your own.

URL scheme for a multi-version web app

I'm looking for the best URL schema to use for a web app that has multiple versions, namely several languages and a simplified version for use by mobile phones - both aspects can be combined, so there's an English regular and mobile version, a German regular and mobile version, etc.
Goals (in order of importance):
User-friendliness
Search engine friendliness
Ease of development
Aspects to consider:
How should the URLs look like?
How should the user navigate between versions?
How much logic should there be to automatically decide on a version?
I'll describe my concept so far below, maybe some of you have better ideas.
My current concept:
When a new user arrives, the app decides, based on cookies (see below), the Accept-Language: header and the user agent string (used to identify mobile browsers) which version to show, but does not reflect this in the URL (no redirects)
It defaults to the non-simplified English version
There are prominently displayed icons (flags, a stylized mobile phone) to choose other versions
When the user explicitly chooses a different version, this is reflected both in a changed URL and a browser cookie
The URL schema is / for the "automatic" version, /en/, /de/, etc. for the language version, /mobile/ for the simplified version, /normal/ for the non-simplified one, and combinations thereof i.e. /mobile/en/ and /normal/de/
mod_rewrite is used to strip these URL prefixes and convert them to GET parameters for the app to parse
robots.txt disallows /mobile/ and /normal/
Advantages:
The different language versions are all indexed separately by search engines
Cookies help, but are not necessary
There'S a good chance that people will see the version that's ideal for them without having to make any choice
The user can always explicitly choose which version he wants (this makes the /normal/ URL necessary)
Each version has an URL which will display exactly that version when passed to others
/mobile/ and /normal/ are ignored by search engines; they would only be duplicate content.
Disadvantages:
Requires heavy use of mod_rewrite, which I find rather cryptic
Users could send their current URL to someone and that person, when visiting it, could end up seeing a different version, which could cause confusion
There is still duplicate content between / and /en/ - I can't disallow / in robots.txt - should I trust the search engines not to penalize me for exact duplicate content on the same domain, or disallow /en/ and accept that people coming to / via a search engine may see a different version than what they found in the search engine?
I suggest subdomains, personally.
I wouldn't include the mobile at all - use the useragent to determine this, and possibly a cookie incase the user wants to view the full site on their mobile (think how Flickr and Google do it). But for languages, yes - primary language at http://mydomain.com/, secondary languages at i.e. http://de.mydomain.com/ or http://fr.mydomain.com/
I am unclear why you would want to incorporate any kind of what you call versioning information, such as accept-language or user-agent, specific designation in the URL scheme. The URL scheme should be indicative of the content only. The server should investigate the various request headers to determine how to retrieve and/or format the response.