Setting the default language to English in admin/config/regional/language has been told by many developers as recommended.
But you can set it to another language as well? If you set in another language all your string translations will you use the other language as default for translations. But how about modules and the default language (source language) for translation that is default always using English as source language.
There is something really confusing here.
You can have English as default language ( set in your global configuration) but at the same time set for example Dutch as default (preferred language in your Content type (language settings) in admin/structure/types/manage/page?destination=/admin/structure/types
If you set Dutch as default language it will be the source language for your content translation.
English not default language was really a problem in Drupal 7, but Drupal 8 has greatly imporoved on that matter and so far only small glitches have been reported and might not be any at this time.
I have build Drupal 8 sites with non-english as default language without any problems.
I would suggest making this decision and change as early as possible in setting up the website and test that id does not have any side effects.
A content type default language different than the Site default is a flexibility offered by Drupal. And the two are used in different parts of the site. What part is consufing ?
For example the screenshot below shows a setup for the following scenario: A native GREEK responsible for WRITING content of this particular content type. The content would be written first in GREEK (3) and than allowed to be translated (1) in available languages. But we also allow an editor to choose another language as the source language (2).
Each one of those language settings is independent.
Related
I have an application that supports English and French. My clients would like the name of the application (i.e. the text that shows up underneath the icon) to be "Friend" if the user's system language is English, and "Ami" if the user's system language is French (made-up names to illustrate the point), and to have this displayed application name change dynamically whenever the user changes the language setting (as opposed to maybe installing it with a different name based on the current language setting).
Is this possible, or is the name of the application pretty much fixed regardless of the system language?
I'm fairly new to Poedit, but I'm trying to make a translation of a Wordpress theme. I think I'm slowly beginning to understand the whole I18n, l10n and po, pot and mo thing.
I've purchased a Poedit license and are then trying to create a new pot-file. When I choose the folder that I'm trying to translate, then it automatically sets the language that I'm trying to translate from to be English (and I haven't chosen it). It's an old theme, that I've modified and used, so some of the words on this image is english, but the theme is actually in danish.
So where do I change the language that Poedit thinks that I'm translating from?
Since this question was answered it became possible to tell Poedit the source language using a custom header field in the PO Header. (Since 1.8.10)
X-Source-Language: de
See: Specify the source language of the PO file
The gettext translation system assumes that the source text is always in English. There are good reasons for it, including the fact that it is the lingua franca of computing and that designing plural forms handling for any source languages would be insane. The absolutely best thing you can do is to develop your code in English.
Consequently, the PO file format (which isn't Poedit's, but a standard thing) has no way to encode the source language — there's no need, it is known to be English.
Some developers insist on using non-English source texts anyway, against their better judgement (this is relatively common in Germany for some reason). To accommodate this, Poedit autodetects the language since 1.8 using CLD2 (i.e. the same thing Chrome uses). There's no way to override this, because... well, see above.
In other words, in your case, Poedit sees the source as English because it is primarily English. If it were in Danish, Poedit would detect that. Case in point: your entire screenshot (save for maybe 1 word) is in English and not Danish as you say the file is.
There are no negative consequences to misdetected source language, except for suboptimal suggestions. Don't worry about it.
I would like to purchase the product Paymill Gateway for one of our customers. His website comes with 3 different languages: German, English and French
As far as I know Paymill supports these 3 languages but how exactly would that work? Can I only CHOOSE between one of those languages or would the details of the page automatically get translated whenever the user switches the language of the website?
I hope somebody has experience with this plugin and can update me with some details.
you should consider trying out the free but official alternative on https://wordpress.org/plugins/paymill/
In the official plugin there are several language packs included which are loaded depending on your language settings in WordPress. The plugin WordPress MultiLanguage can help to serve different languages and switching between them.
Please also note that support requests may be faster handled on official support forum https://wordpress.org/support/plugin/paymill
If you are using the paymill.createToken function, validation happens in JavaScript. The function passes an error object in its callback; the error code can be accessed through error.apierror.
You can build a language map to display the error message in different languages. For example:
var messages={
'en':{
'field_invalid_card_number':'Invalid Card Number',
'field_invalid_card_exp': The card has expired'
},
'de':{
'field_invalid_card_number':'Ungueltige Kartenummer',
'field_invalid_card_exp':'Die Karte ist abgelaufen'
}
}
Then with some additional logic you may display the suitable target language.
in my view's exposed filters block the taxonomy terms are showed only in the original language version (in English).
Vocabulary is set to Localize terms.
The terms are translated via Translation Table.
All the other content (Views, nodes, translated strings etc.) is showed correctly (in German).
I'd expect them to appear in current language, however.
Here for instance, I'd expect to have German Sommer 10 instead of English Summer 10.
Do You have any idea how to solve it?
I use Drupal 6 and Views 2.10
I have found a patch to make taxonomy terms appear translated.
Unfortunately, it seems that the it's not a bug but just a not (yet) implemented feature (see this and that).
(...) The reason that there is a difference in node behavior is that the module you're using for taxonomy translation modifies the node. It would have to modify the view as well. Drupal core doesn't support translating vocabulary. I am happy to (...) make sure it has the capability to help with Views translation, but you must understand that this is:
1) not automatic
2) not views' responsibility.
We're building a multi-language Drupal stack and one of the concerns we have is that our payment processor is going to have to send back some information to us. We've been able to narrow this down so that the strings they're sending back look like
<country code>-<number of months>
so we can easily translate that into any number of languages, except English.
t('FR-12') is all well and good if we want to translate that into a french description, but because there's not an English language a similar string like t('EN-12') is not translatable.
Similarly for the generic string: #API_Connection_Error
This sort of generic string approach seemed really compelling to me at first but it seems to not work in Drupal. Do you have any suggestions about how to translate generic strings like this into both English and other languages?
Thank you, I've been looking through Google all morning.
I see two ways to achieve this at the moment:
You could just replace the default English language definition with a custom version. That way, you can 'translate' selected English strings just as with any other language. If you have configured locale module to fallback to the original string in case of absent translations, you can just add your special cases as translations to your custom English version, and everything else will use the original English version.
Take a look at the String Overrides module - it allows you to define custom overrides for any string that gets passed through t(), with separate overrides per language, including the original English.
I'd use the second option in your case, except if the number of 'external' strings is very high. See the first if clause of the t() function for the mechanism used for the overrides (lookup in language specific Drupal variable arrays).
Note that the String Overrides module just adds admin UI pages to configure those Drupal variables in the Backend - you could add/adjust them yourself as well (e.g. from a custom module).