Internationalization for richfaces custom skin - internationalization

We are using some custom skin for rich faces and below are 2 properties file for packed and packedCompressed
mySkin-packed-resource-mappings.properties
mySkin-packedcompressed-resource-mappings.properties
This property file has a mapping for home_icon e.g.
images\:home_icon.png = org.richfaces.staticResource/4.3.5.Final/Packedorg.richfaces.images/home_icon.png
My questions are:
How these does this mapping is used for richfaces custom skin? as I
could not find any reference in my code for this key
images:home_icon.png
Does richfaces support internationalization for custom skin
resources like above one?
If answer to above question is yes and assuming that this mapping is
for default English language, how can I add a mapping for another
language like Arabic?
Please correct me if I have understood it wrong?

Skin has nothing with internationalization. Skin properties setup colors, fonts, font sizes for different parts of UI. Internationalization files used for text setup and not related to skins.
About your questions:
1) regular RichFaces skin property file does not contain icon related properties, like images\:home_icon.png;
2) internationalization is not related to custom skin;
3) you can add internalization support for any language you want, but it is not related to skin properties.
On other side, it is totally valid to use background-image: "#{a4jSkin.imageUrl('inputBackgroundImage.png')}"; in ecss files, but it has nothing with internationalization.

Related

Drupal 8 stripping style attributes from table tags

I'm using Full HTML filter, with CKEditor. The following filters are enabled:
Align images
Caption images
Track images uploaded via a Text Editor
Collapsible text blocks
Note that Limit allowed HTML tags and correct faulty HTML is NOT enabled.
when I add a style attribute to a table element in Ckeditor using the Source view, specifically "width=75%", it is stripped when the page is rendered. When I edit the page again and go to Source view, the style tag is there.
What is stripping it on render?
I believe inline styles are removed by default for security reasons. But, there has been a lot of discussion about this issue on Drupal.org over the past few years. If you're looking for a workaround and accept the risk, here are two approaches I have found:
How to fix: CKEditor is removing style attributes. Drupal 8.
Refactor Xss::attributes() to allow filtering of style attribute values
Fair warning: I have not personally implemented either of these.
Inline style is stripped by default with Basic HTML formatter. Unless you have a specific reason why you don't want to turn on Limit allowed HTML tags I highly recommend that you do because it gives you a lot of control over what tags you and others can use in the wysiwyg. In addition, it allows you to add a "Styles" button with pre-configured styles so you don't have to insert inline CSS code repetitively.

AEM How to prevent localization happening otb?

I have a scenario wherein i18n becomes overhead to content authors. The authors want dialog labels to be in English only for all locales. But certain headings/labels on dialog gets localized as they are available in otb dictionaries. Example label 'Advanced' from page properties dialog gets translated for non-english sites.
Is there a way I can prevent internalization happening?
If you refer to AEM's documentation for i18n, you can see its driven by the locale/language set in slingRequest. you can override this by explicitly fixing the i18n but if you do that none of your translations will work -
Locale pageLang = new Locale("en");
ResourceBundle resourceBundle = slingRequest.getResourceBundle(pageLang);
I18n i18n = new I18n(resourceBundle);
An other alternative (a little extra effort) in you need to do this only for dialog boxes is -
Create your own dictionary for translations, refer here
Use unique name-spacing for your keys eg - myapp.mycomponent_abc.label
Use above keys in your component dialog to ensure that your version of translation is picked. If for all languages you want english only dialogs, all your have to do is duplicate your english dictionary and change the language key in it to relevant language while keeping translations still in english.

Telerik Reporting Styles

I have just started messing with Telerik Reporting in an MVC C# application.
Since I need to create a dozen of reports, I was asked to create an external style to be aplied to all of them.
I cannot understand how it works, how to set the rules...
Eg I can create a style to affect all HtmlTextBoxes BUT I am trying to create a rule to have all the HtmlTextBoxes contained in the Group Header having (lets say) blue Background, Bold Segoi Font and I cannot.
Any help appreciated
Styles created in a Telerik Report can be exported and then used in other reports.
You can store one or more Styles in an exported file.
The exported information is stored in an XML file.
So you can create your style rules using the Style context menu Right-clicking on the report object.
Style exporting and reusing style sheets
Use various Style Selectors to define how a style will be applied globally to items in a report. Each Style Rule that you create (either in code or using the StyleRule Collection Editor) must be created as one of the basic four selector.
Learn more about style selector.. For me the best one is the "StyleSelector" that behave like a Css Class.
Nb:
You can manage and bind your extenal StyleSheet in code behind.
Or in your calling application.
this.StyleSheet.Clear();
this.ExternalStyleSheets.Add(
new Telerik.Reporting.Drawing.ExternalStyleSheet("baseThemeRpt.xml"));
It can be done using the Descendant Type

CKEditor Stripping Out Some of Our CSS classes

We are having a problem with CKEditor (ver 4.1.1.5) stripping out some of our css classes when we are editing in the FULL HTML mode using SOURCE. From looking at some of the other questions posed on this, the Advanced Content Filter is the place we should be going. And, if I read this correctly, we need to edit the config.js file to add: CKEDITOR.config.allowedContent=true;
Am I going in the right direction? I want the WYSIWYG to still work for people with no html experience. However, when we go into source, I want all classes to remain and not be stripped out, no matter what.
You are partially right:
Yes, Advanced Content Filter (ACF) is the mechanism responsible for this.
But no, setting config.allowedContent to true is not a correct solution.
In short, ACF is a useful mechanism that lets you easily control the content that your users add to your site with CKEditor. Instead of disabling it, however, you should extend the filter configuration to accept whatever additional elements, classes, styles, attributes you want to allow.
In your case, if you want to additionally allow all classes for all elements, use this in your editor configuration:
config.extraAllowedContent = '*(*)';
Read more about ACF here:
Content Filtering (ACF) - introduction
Demo of Automatic Mode and Custom Mode
Advanced Content Filter - more advanced
Allowed Content Rules - syntax for ACF rules

JasperReports - Conditional style per locale?

Is there a way to use a different styles, or redefine a style, based on a report parameter locale? I need to modify font sizes for certain languages.
I have implemented this in the past using external style templates. There is a sample on jasperforge that illustrates how to do this.
Once you've moved your styles to external templates, you can create locale specific templates. The templating mechanism allows you to inherit from and override specific styles, so the locale specific versions don't get overly bloated. The example I linked above includes inheriting from and overriding base styles.
In your reports, you can then load the appropriate template at render time.
One easy way to do this is:
provide the path to the template that you want to use as a parameter
to the report
include a template tag in the jrxml file that references the
parameter:
<template><![CDATA[$P{TEMPLATE_PATH}]]></template>
Then, in the code that renders the report, just set the TEMPLATE_PATH parameter appropriately for the report locale.
Again, the linked documentation mentions how to do this.

Resources