Does anybody know, if in Liferay is possibility to use default value in ui message ? I mean I have two files .properties with translations, for example: en.properties:
welecome=Hallo everybody
someKey=
,and default.properites
welecome=Hallo everybody
someKey=value of some key
I want to achieve, that if I use:
<liferay-ui:message key="welcome" />
<liferay-ui:message key="someKey" />
with English language (where there is no translation for key 'someKey'), the displayed value will be:
Hallo everybody
value of some key
I mean, when there is no translation for some key, liferay portlet will use value from default properties file.
regards
With the standard naming conventions, you typically have files like Language.properties and Language_en.properties. When english language is displayed, but the entry is not contained in Language_en.properties, I expect the value from Language.properties to be shown.
However, in your case you define someKey as an empty value, which means that it's defined as exactly this.
Moreover, Liferay offers a "Language Builder" tool that you can run during development time (in the plugins-sdk just run ant build-lang. It will create configured language files automatically, automatically copying the values from the original file if they are not yet contained in the translated file.
If you have api credentials for bing, it can also use these to get an automatically translated value for various languages, but I'm not a big fan of these. Actually, I'm quite annoyed by automatic translations.
Related
How can i localize the drop down option for the search mode? I did some digging and was able to adjust the localization for the search form labels but i'm at loss here.
The CMS Module SearchDialog.ascx call the drop down list here, but i can't see where the values come from.
<cms:CMSDropDownList runat="server" ID="drpSearchMode" CssClass="DropDownField" />
Go to the localization App and create resource strings for
"srch.dialog.AllWords"
"srch.dialog.AnyWord"
"srch.dialog.anywordorsynonyms"
"srch.dialog.ExactPhrase"
Believe those are the 4 you need.
I couldn't find official documentation that helps much with this, though there have been articles in the past on older versions. However, one trick I've used previously is to look in the ~/CMSResources/cms.resx file, find the localized string there, and add a new one with the same key to the Localization module in Kentico. That is, add a new resource string in Kentico with the same key (the naming will be different depending on your version of Kentico).
Here's the docs discussing setting up a multilingual interface: https://docs.kentico.com/display/K9/Setting+up+a+multilingual+user+interface
And here's a screenshot of the resx file:
So in your case I'd create a new resource string within Kentico called "srch.dialog.allwords" as an example and that should overwrite and take priority over whatever is in the .resx file, plus you can manage it via the Kentico admin. There may be a quicker or more reliable way to view the list of default resource strings but in my recent installs of Kentico, the list is hidden from the admin interface.
Alternatively, of course, you could manage the resource strings via various .resx files as in the documentation, but I try to manage as much of these pieces via Kentico as possible for convenience.
Not really that easy question here. :)
A customer has a field ownerid that is used as the lookup to a salesperson. I've changed the text of the label from Owner to Hazaa and I can see it take effect.
The problem is that Hazaa only displays in the English version (the base language of the installtion), while the language that is used for the users is Swedish. The users with Swedish language selected see the default translation, while they'd like to see Hazaa instead.
How can this be done?!
I could, perhaps, play around with exporting the language for translation, editing it and, then, importing back. However, that's a little, tiny, wimsy bit overkill for changing a single label. However, I suspect that only a few entities will require hazaa-fication of the ownerid field, while the rest is supposed to be left as is.
The supported way to translate the label is using the translation process (an example can be found here)
Maybe you can consider to create an unmanaged solution that contains only that entity, in order to export only the necessary labels.
There is also a tool recently released by Tanguy Touzard in his toolbox, I didn't use it yet, but you can find more information here:
http://mscrmtools.blogspot.com/2013/08/new-xrmtoolbox-plugin-easy-translator.html
Two questions, hopefully with similar answers.
I'll be releasing a JavaScript package in my solution where the error messages are to be displayed. The problems is that I'll be targeting German, English and French. Possibly, also a fourth language TBD. What would be the nicest way to resolve this?
The label names should definitely be localized. Is there a built-in approach to that in CRM 2011? Like a resource table or something like that?
My current solution for (1) is to keep an extra web resource with the strings and distributing a different file for each language. I may rebuild it and distribute all the languages at once and only use a parameter, possibly settable from the GUI if I create a settings-entity. A bit cumbersome.
My current solution for (2) involves a lot of praying and a divine act of some sort. :)
To determine current CRM user language dynamically from Javascript you can use window.USER_LANGUAGE_CODE (this variable exists on all CRM pages) - for example it will be equal 1033 for English. Than based on that info, you can pick needed string resources from your file.
Also in forms context there are two predefined functions, which return current Organization language code and current User language code: Xrm.Page.context.getOrgLcid() and
Xrm.Page.context.getUserLcid() .
If you are talking about custom entities and fields, you can easily add localized display names for them via your solution. You need to edit customizations.xml file from your unzipped solution. For each attribute there you will find such XML containing display names:
<displaynames>
<displayname description="Created By" languagecode="1033" />
</displaynames>
You can just add new display names for each language you need there.
P.S. If someone interested in different aspects of multilangual support for Dynamics CRM 2011 solutions, I strongly recommend to review this page, also here and here is a very helpful reading.
I need to change the language of whole project. I am using jsf. In default I used English. Now i need to convert it in Italian and Spanish.
I did it by manually writing in the property class. Just like:
and in xhtml I need to to put the property by manually.
My question is that, is there any way to convert it automatically?? I mean I just click on Italian, and it will display in italian language.
You need to create one file by language (with the correct name)
And fill every - key manually ...
Netbeans help you to display all languages in the same table.
The automaticaly option is Google trad.. it's not good solution.
I asked about locale translation here Magento: how to translate action tag content?. At the same time magento has translation themes:
app/design/frontend/default/default/
app/design/frontend/default/french/
app/design/frontend/default/german/
If we can do translation in locale files what are design folders for then? (In case we have the same theme for each language). Or is it implied that I should use design folders only when I have different themes?
Actually, a single theme can contain multiple translation locales. The following would be perfectly possible (though obviously not advised):
app/design/frontend/default/french/locale/de_DE/translate.csv
Storeviews are often used for switching between languages, because it is quite easy to set a locale on store-view configuration scope from the backend.
To answer your question more direct, I would suggest that you:
Install an initial language in app/locale/(code).
Anything that deviates from this 'core' locale, to be put in app/design/frontend/(your_package)/default/locale/(code)/translate.csv.
This leaves you room to do overrides in non-default themes at any later point.