i need to localize a Reporting Services-report (.rdlc) and i would like to do it using a ressource-file (.resx).
I found pages like this and that and they use custom code to achieve their target.
But pages like Setting the Report Language Parameter in a URL give me the impression that localization in reports is possible without custom code.
So, it is possible to localize a Reporting Services-report without custom code ?
If so, is there a tutorial that explains how it's done?
What in the report do you want to localize?
values from the database? Those should be retrieved from the database in the appropriate language already
fixed labels and textboxes on the report? I have not yet seen any compelling way to doing this - you can either have
one report "skeleton" / template per language (and pick the one you need)
if the number of elements is manageable, define report parameters which you can set from the calling code, to set the labels and texts
use some custom .NET extension for handling localization
It's not really an awfully pretty picture, indeed - I'd be most interested in better solutions myself! (I typically need to support 3-4 languages for any report - and I'm using only server-based .RDL files, no .RDLC, so any localization that depends on client-side resource files is not usable in my case)
I would add one method when it comes to labels and textboxes:
Create a placeholder element within the textbox and use Expression field to
use a Switch clause , switching on the Language parameter.
It's not superpretty, but also works pretty well for 3-4 languages
I am passing parameters to the report for labels etc, and after adding the parameters to the report (using the menu option Report -> Parameters in VS2008) you can then use the values of these parameters to localise the labels. This is workiiing well enough, although it would be nicer to be abkle to refer to resource keys immediately from your form labels etc.
Related
I have an app that is used to track/manage livestock. It currently supports one species, Sheep. We want to begin supporting multiple different species, like Goats, and Cattle. My first thought was to create something similar to NSLocalizedString(text, comment) like SpeciesString(text, species, comment) which would take the English string and the species name and translate the Sheep term Ram to the Cattle term Bull. And internal to that, I could use NSLocalizedString() to then further translate that to the proper language so that in the future I could support multiple languages as well.
I see that I can pass a tableName to NSLocalizedString() so that it will use a different file other than Localizeable.strings and that would allow me to programmatically pull values from a Spanish language file that is focused on Cattle instead of Sheep (something like Localizeable-sheep.strings and Localizeable-cattle.strings), but that won't help me with all of the text that is in the storyboard.
I know that there is built-in support for localization with the storyboard, but the problem I'm having is that when the text comes to my code, for example in viewDidLoad, it will already have been translated to the other language, for example Spanish. I would prefer to find a way to make the text in my views already have the right Language+Species combination by the time it gets to my code. But even if I did rely on programmatically swapping out the strings to use the right Species, the English will already been changed to Spanish and I'll get Carnero instead of Ram and if I try to pass that through to my SpeciesString() it won't match my underlying data, because my underlying data is keying off of the English version of the text.
Is there a way to create a custom language? I've seen this code that is used to change the localization language on the fly, and it works for swapping between en and es, but I can't create my own fake languages like en-sheep and es-sheep.
Is there either:
a) a way to create my own custom language so that the localization system will just pick my correct Language+Species combination?
or
b) a way to tell the Storyboard which table name/filename to pull strings from? So that instead of just having a strings file for my Main.storyboard be called es.lproj/Main.strings but I could instead have
es.lproj/Main-sheep.strings and es.lproj/Main-cattle.strings?
I think my inability to get my "custom language" to work was just an accidental oversight. I created an es-sheep.lproj/Main.strings and used the other SO post to programmatically set my language to es-sheep and it didn't seem to work...
... but it turned out that I had created those directories and files, but forgotten to add them to the project. Once I manually added them to the project, it started working and I was able to use my custom localizations.
I have question related to the Ranorex Spy.
Is it possible to recognize (by default) elements of the page by attribute other than id, e.g. data-id
I know that I can modify this later manually for each element (but it is time consuming)
Currently:
\input[#id='..."]
Expected (automatically, by Ranorex Spy):
\input[#data-id='..."]
I personnally did not bother using this (because we use many frameworks and whats desired in one framework is not necessarily whats desired in another one) but I think you can achieve priorisation of XPath rules using the RanoreXPath Weight Rules.
Following is a Ranorex article describing how to do this: http://www.ranorex.com/support/user-guide-20/ranorexpath-weight-rule-library.html
Good luck!
We recently upgraded our Kentico 8.2 instance to 9.0 and are now focusing on localizing our site into two additional cultures. The textual content of our site is primarily stored in one of three places:
Editable regions
Text fields in custom page types
Custom tables
We're using the Kentico EMS license and would like to leverage the built-in Translation Services app in order to translate content in each of these locations, however it appears that it only supports with content within editable regions. I know Kentico has an input control for translating text boxes but it forces the content editor to create a distinct resource key for it; we simply have so much content I'm concerned this will get out of control for editors.
Additionally, we had considered migrating some of our content into pages but they don't logically fit there, and there are some complex relationships that would cause duplicate content so I'd really prefer to keep the content where it is. The other thought I had was to build either a custom module or custom form control to do some dirty work under the covers but didn't want to reinvent the wheel if there was already a known approach.
Is there a Kentico recommended approach, or workaround, to managing content translations within custom tables and page type fields?
You can use Translation in Kentico to translate page type fields and send them for translation. Check this documentation page for an example. It can be more complex at first, but it should do the trick for you. I have just tested creating a simple translation request for my page type and the resulting XLF file contained all page type fields.
For custom tables I will have to dissapoint you because custom tables in Kentico are not culture specific. If performance is important for you the best way to create translations is to add CultureCode field to your table in order to specify which culture the item is for.
For example you can have table with columns: ItemID, Text, CultureCode
And then the data would look like:
1, Dog, en-US
2, Hund, ge-GE
3, Pes, cs-CZ
If you would want to go even step further I would recommend to create this not as a custom table, but as a Custom class which will sit inside a custom module for which you can create your own interface which would allow editors to easily create all culture versions for the items.
For the custom page types and custom tables, you can change those text fields to localized text fields at the field definition and it will allow you to enter different values per language without a resource key. This is the best route IMHO for page types and custom table translation. Although this still does not allow for "automatic" or built-in translation.
I am not sure what do you mean by content translation in page type fields - there is support for translating page type fields. You can find example on sample site in Kentico installation. (The site is called DancingGoat - see image example for page type field localization in english and spanish language).
I have received a requirement to amend the translations of the 'Add new..' and 'Add existing..' buttons in French. A typical default button is shown below:
The desired new translations are essentially to remove the gender neutrality (if my rather poor school French is correct!). So rather than 'Ajouter un(e)' we have 'Ajouter un'.
Unfortunately these button labels are not included in the standard translations file (Settings -> Customisations -> Export Translations).
Are there any other options available? Given the nature of the requirement, I am happy to consider pretty much any kind of hack. CRM must be generating these values from somewhere, any ideas where they are hidden?
Note: I profoundly disagree with this requirement for fairly obvious reasons and I am sure most people reading this question will as well. However, requirements are what they are and sometimes customers/clients just will not budge. This is one of those cases.
You can define the labels for CRM Ribbon controls. See Use Localized Labels with Ribbons.
In order to make this work, you need to export the ribbon definitions and identify where these controls are defined.
You should be able to define a CustomAction to override the definition of the existing control but include the label text you want to have instead of the default label text. See Define Custom Actions to Modify the Ribbon.
If you are already experienced with customizing the ribbon this shouldn't be too hard, but there is a signifcant learning curve when it comes to customizing the ribbon.
Tagsoup is interfering with input and formatting it incorrectly. For instance when we have the following markup
Text outside anchor
It is formatted as follows
Text outside anchor
This is a simple example but we have other issues as well. So we made tagsoup cleanup/formatting optional by adding an extra attribute to textarea control.
Here is the diff(https://github.com/binnyg/orbeon-forms/commit/044c29e32ce36e5b391abfc782ee44f0354bddd3).
Textarea would now look like this
<textarea skip-cleanmarkup="true" mediatype="text/html" />
Two questions
Is this the right approach?
If I provide a patch can it make it to orbeon codebase?
Thanks
BinnyG
Erik, Alex, et al
I think there are two questions here:
The first Concern is a question of Tag Soup and the clean up that happens OOTB: Empty tags are converted to singleton tags which when consumed/sent to the client browser as markup gets "fixed" by browsers like firefox but because of the loss of precision they do the wrong thing.
Turning off this clean up helps in this case but for this issue alone is not really the right answer because we it takes away a security feature and a well-formed markup feature... so there may need to be some adjustment to the handling of at least certain empty tags (other than turning them in to invalid singleton tags.)
All this brings us to the second concern which is do we always want those features in play? Our use-case says no. We want the user to be able to spit out whatever markup they want, invalid or not. We're not putting the form in an app that needs to protect the user from cross script coding, we're building a tool that lets users edit web pages -- hence we have turned off the clean-up.
But turning off cleanup wholesale? Well it's important that we can do it if that's what our usecase calls for but the implementation we have is all or nothing. It would be nice to be able to define strategies for cleanup. Make that function plug-able. For example:
* In the XML Config of the system define a "map" of config names to class names which implement the a given strategy. In the XForm Def the author would specify the name from the map.
If TagSoup transforms:
Text outside anchor
Into:
Text outside anchor
Wouldn't that be bug in TagSoup? If that was the case, then I'd say that it is better to fix this issue rather than disable TagSoup. But, it isn't a bug in TagSoup; here is what seems to be happening. Say the browsers sends the following to the client:
<a shape="rect"></a>After<br clear="none">
This goes through TagSoup, the result goes through the XSLT clean-up code, and the following is sent to the browser:
<a shape="rect"/>After<br clear="none"/>
The issue is on the browser, which transforms this into:
<a shape="rect">After</a><br clear="none"/>
The problem is that we serialize this as XML with Dom4jUtils.domToString(cleanedDocument), while it would be more prudent to serialize it as HTML. Here we could use the Saxon serializer. It is also used from HTMLSerializer. Maybe you can try changing this code to use it instead of using Dom4jUtils.domToString(). You'll let us know what you find when a get a chance to do that.
Binesh and I agree, if there is a bug it would be a good idea to address the issue closer to the root. But I think the specific issue he is only part of the matter.
We're thinking it would be best to have some kind of name-to-strategy mapping so that RTEs can call in the server-side processing that is right for them or the default if it's not specified.