We have a huge number of Page Reports created using ActiveReport (*.rdlx files)
We use them from our ASP.NET MVC web appolication.
All captions and other stuff were initially created on English
Now we need to add a multilanguage support there so, somehow we need all existing texts be inserted in resource file and so we can then add translations
Is there a way to achive this task quickly, without going to each report field and manually extracting it into resource file?
Documentation says that once you change Language property, resource files will be created, but seems it is not working for XML reports, or there shouldbe a trick
For the reports designed with Code-behind, resource files are created pretty much the same as if you will create a Windows form... but I fail to find out how to do this for XML reports.
Page Reports support a localization; however it doesn't do so with a resource file.
This is mentioned off-hand in a single sentence on the page about Localization with ActiveReports 7.
Setting up a localized value in a Page Report is done the same was as you do in a Section Report. Simply change the report's Language property and then set new textbox values. At report runtime the appropriate value for the textbox will get used.
As I mentioned above, this doesn't generate a separate .resx file; instead if you inspect the resulting .rdlx you'll find a custom dd:LocalizationResources element is created that specifies the language setting and the new values for report elements.
The Localize property you are referring to in the documentation and in the code-behind reports are for the code-based "Section Layout" Reports but won't work for XML-based "Page Layout" reports (if you look at the generated code for the report, you'll see that the designer is just generating a bunch of code to localize the report).
Since code-behind reports support custom code or you can add references to another DLL you can write a simple function to localize captions. There is a good example of localizing this for .rdl reports here, you can use exactly the same approach with the ActiveReports' .rdlx files.
During that initial configuration of the report to be localizable you'll either have to manually change each static string to a Code.LocalizedValue call or maybe you could write a simple script to find each //Textbox/Value elements and replace it with a similar call. A simple script with a combination of xpath and regex could do help you automate the initial configuration of the report. To localize something other than a Textbox Value in the report (e.g. report parameter, labels/bookmarks), you'll need to replace the text of a different element than the Textbox Value but the concept is the same.
Of course, I am assuming you are localizing the static strings in your report. If you want to localize the values from the database then you'll have to do that differently (comment if you need help and I'll explain).
Related
I am trying to generate specflow mstestexecution report with the screenshots path mentioned as link. I made use of Console.Writeline() to mention the screenshots path but its getting dispalyed as text in the report. Please provide your inputs on the same.
The HTML report sees everything as plain text even if you use HTML tags. This is by design. You can change the behaviour of specflow.exe yourself, it is an open source project on GitHub.
When you don't want to dive to deep into that, you need a more ugly work around: You could consider to tag your links with another token (like {img} instead of ) and than search and replace in the .html file for all {img} to for example.
We're currently at the stage of looking at localising our app in to multiple languages now that the general concepts of the app have been decided. This is something I want to ensure is done correct from the start to lower the risk of headaches in the future.
The app targets iOS 7 and above, uses storyboards, and is written in Swift.
Storyboards
When working with a storyboard (or a xib), what's the best way to mark a UI element as "not to be translated"? For example, I have a placeholder string for a user's display name (Display Name), which will be replaced by a users display name at run time. This display name will not be localised, but neither should the string "Display Name". Is there a method of not having a UI element's value automatically put in to the strings file? If not, is going in to that file and manually removing strings I don't want localising a sustainable option?
Strings In Code
I'm using the Swift function NSLocalizedString with the key and comment parameters. Some places I've seen say to set the key to be a unique id based on the context (e.g., intro.login-button-text), while others seem to just put the full string in the default language (e.g., Login). I like the idea of the unique ids for the key, but would this not go against the idea of the "base" language?
Exporting
Xcode 6's "Export For Localization" option seems very useful for getting the correct format of file to be sent to translators. However, as mentioned previously, placeholder text does not need to be translated. Should these placeholders be removed from the exported xliff or the strings file prior to export?
Looking for the the same questions myself. Hope this will help you and others. Also I would recommend to have some kind of tool to organize the xliff/string files
Storyboards:
I've seen developers putting non translating texts in storyboard with extra parentheses. i.e. {Display name}.
By using this you can see by the translation itself if it needs to be translated or not. We use oneskyapp.com and can select to hide those translations and they will be hidden for each import of that key.
Strings in Code
By following this thread they suggest to use keywords.
Best practice for key values in translation files
Exporting
I cannot find a way to have some translations automatically removed when exporting. Off course you can put the views which has dynamic fields in different XIB/storyboards and decide not to translate those.
Again a tool like onskyapp.com can help you with this.
Formats
As of context with the field is important and a translation can be different when it is followed by i.e. a users name I would go for "%1$# is online!"
Due to timing constrains, I have developed a web application where a lot of language-specific strings have been directly hard-coded to large HTML/Javascript static files. Due to poor coding, code and content have not been properly separated.
To achieve quick and dirty localization, I am looking for some kind of text editor that would allow to "tag" the local elements of a file and turn them into "custom fields". These fields could then be stored in some resource file and translated independently from the shared structure, to generate multiple localized versions of the file.
I realize that I could do this myself through a "simple" templating mechanism, for instance by keeping a shared root file containing fields like {%welcome_message%} and a csv file for field translations, and then generate localized files.
But is there a text editor that could do this in a fast, user-friendly way ? For instance where we could see/modify the custom field values (as well as the root parts) directly when editing a file ?
What would be great for instance, would a a text editor feature/plugin allowing some kind of parallel file editing by distinguishing "root" and "localized" parts in a set of files.
(Note : currently I am using diff/merge tools to achieve this kind of results, but it will become increasingly cumbersome as we add more languages).
I think this could help you in parallel file editing http://www.sublimetext.com/.
I recently upgraded to Excel 2010. I was working on a spreadsheet and wrote some code and went to save it and I get this box that pops up. I'm not sure what to do.
From Office 2007 on, Excel has two different file types: XLSX and XLSM. The former is just data and formatting without macros or anything "dangerous." The latter allows macros and other programmatic functionality. The reason for the split is mainly security as each one has a distinct extension and icon to better inform the user on whether or not the file could potentially contain dangerous content.
In this instance, you need to click No, then in the Save As... options select "Excel Macro-Enabled Workbook." That will give you the full functionality of the original document.
I have written several applications in Delphi which use Word automation. The programs all use templates which are stored in a directory. In pre-2010 versions of Word, one would define the location of the templates in tools|options|file locations; the programs would pass the name of the template and Word would know where to find it.
My client has now moved to Office 2010, and as a result, Word cannot find the template when started by my programs. I haven't been able to find a similar dialog box in Word in which I can define the default directory for templates. How does one define such a directory?
Click File | Options | Advanced | File Locations and you get the same dialog as in older verions
Instead of forcing your user to configure Word to define the location of templates, you might prefer to invoke word using /t switch.
/ttemplatename starts Word with a new document based on a template other than the Normal template.
>"%programfiles%\Microsoft Office\Office14\winword.exe" /t"c:\MYTEMPLATES\mytemplate.dotx"
Can't you just specify the full path when creating a new document? Why rely on a settings that possibly can even be changed by the user? Put your templates in your own folder and specify the full path.
Word's paths configuration are stored
You can get the USER template folder via
Word.Application.Options.DefaultFilePath(WdDefaultFilePath.wdUserTemplatesPath)
(there are others options for that property too).
As far as I can tell, the template loading rules haven't changed from 2007 to 2010.
Generally speaking, if your add in needs to load a template, you should specify the FULL path and file name to the template, but you can get the typical user path via the above.
On the other hand, if you install the template into WORD\STARTUP, word will automatically load it. that may not be what you need/want, though.
Finally, if your template doesn't/shouldn't change, it might be better to leave it in your PROGRAM FILES\appname folder and load it from there.
Generally speaking, +requiring+ users to change the FILE LOCATIONS in word (or changing it programmatically) is a bad idea, just because so many people wouldn't have a clue, and those that do definitely DO NOT want addins changing those settings automatically!