About Translate JMeter projects,
I follow the translating steps and open I18NEdit,
I see the translation text options but I notice that I can't localize Menu items as File, Exit,..
It seems that there are texts (messages.properties) that can't be localized.
Is messages.properties localization is done manually by adding messages_[locale].properties?
Am I missing something ? Is it on purpose or should an enhancement be opened?
We don't really use i18nedit for translation. But you can still use it.
Anyway, Internationalization in JMeter is based on properties files:
src/core/org/apache/jmeter/resources/messages_[locale].properties
src/components/..../*.properties (except some like colors.properties)
src/protocol/..../*.properties
No need to translate deprecated components.
The 2 latter are related to components that rely on TestBean approach (no specific GUI)
Note that a PR (github mirror) is preferred over a patch:
https://github.com/apache/jmeter/blob/trunk/CONTRIBUTING.md
Related
So I am trying to learn a bit more about TYPO3 and Localization. So I am using the Extensions:
L10N-Manager
Localizer
I can create the base Localizer-Configuration but whenever I go into the Selector Tab and try to create a new Cart, I can't select any languages - which makes the created Cart "breaking" (a "global cart" is created but all fields are not available for editing and I can't view it in the Cart Tab of the Localizer)
I am wondering what I am doing wrong - I sadly didn't find any records on such problems or a better introduction about the configuration. All Tutorials just show how the Localizer Configuration is created and then they can simply create a cart.
Is this a known problem? Would be great if anybody knows a solution. Or a really good tutorial that shows step by step how to set up the configuration.
Info: I am using TYPO3 on my localhost (XAMPP) with TYPO3 Version: 10.4.13
Thanks ahead
The Localizer manual says for both, source and target language fields:
Important
Make sure each of the language records has been configured with the
necessary locales to distinguish between languages during the
translations process.
So did you configure the language records accordingly?
Most likely the locale values based on static_info_tables records have not been set, which is currently still necessary. So you should check your sys_language records for those values.
In upcoming versions of Localizer this will be replaced with values taken from the site configuration.
I was hopping to have an easy way to customize the display behavior of the Grails fields plugin after reading its docs, but I just realized that it demands an enormous effort as there is no available templates to start from.
I can see the display functionality is hard-coded in FormFieldsTagLib (from methods like renderDefaultInput() ) but I think it is imperative to have the templates themselves (or a way to generate them, somewhat like generating static scaffolding in Grails).
I can see no consistent (and reasonable) way to customize display behaviors for the Grails fields plugin without that. Am I missing something?
Imagine the use case where someone wants to change the boolean default rendering just to display the field label after (and not before) the checkbox, and keep it available to all the boolean fields within its application. Which concerns will he need to handle regarding if the field is required, has errors, prefix and so on? When all he needed was just moving two divs around.
Grails version: 2.5.4, fields-plugin version: 1.5.1
You aren't missing something. You'd have to re-create the existing implementation of each field type rendering in a template for use with the plugin. There isn't a way to generate a file to start with (like scaffolding).
I won't bore you with the historical reason as to why this is the case, but if you do create a set of base templates it would be a good idea to contribute back to the plugin.
I had an issue with the <f:table> tag, and found this post, which led me to find the base or default template inside the plugin repo.
Take a look at
https://github.com/grails3-plugins/fields/tree/master/grails-app/views
That may help you finding some default templates, along with the official doc and this answer on where to put the override.
Hope it helps you.
I have an Adobe Activation (DTM) container that I would like to dynamically set the reporting suite value using data elements, such as "%reportingSuiteProd% and %reportinSuiteStage%.
When I try to use these values within the Adobe Analytics tool, they are passed as strings instead of using the data element functionality. Is it possible to use data elements here? If not, what is the cleanest way to set a dynamic reporting suite value within DTM?
Example:
http://trackingserver.com/b/ss/%reportingSuiteProd%/1/JS-1.6.1-D6I2/s53779788912776.....
For reasons unclear to anybody, Adobe does not allow data element references to be used for the report suite fields. If you want to use a data element to populate the report suite, you will need to change the settings in Library Management.
Set the Code Configuration to "Custom" and then check the checkbox for "Set report suites using custom code below".
Then, within the "Code Hosted > In DTM" Editor (or within the Customize Page Code Editor) you can do this:
if (_satellite.settings.isStaging)
s.account=_satellite.getVar('reportingSuiteStage');
else
s.account=_satellite.getVar('reportingSuiteProd');
The major downside to this is if your previous setup was to have the Adobe Analytics library Managed by Adobe, well, that is no longer an option, and you will need to ensure the library is kept up to date yourself.
The answer provided is correct, but i recomend instead of put the report of the suit directly on the data element, save the data first and then use it.
In my personal experience, do it in that way only solve some issues related with the pageview and no with the interactions, if you use local var you provide a robust solution:
The code is
var reportSuite;
if (_satellite.settings.isStaging)
reportSuite=_satellite.getVar('reportingSuiteStage');
else
reportSuite=_satellite.getVar('reportingSuiteProd');
s.account = reportSuite
Interpreted languages such as PHP allow a separate file, often called config.php, to contain string constants such as server names. This facilitates deployment, as the config file is simply not uploaded when the code is updated - the server names, e.g. for REST transactions, are typically different in the deployment environment.
In Dart, since it is compiled, this approach does not work. If there are server name constants which are referred to in the HTML via {{ }}, it seems the code must be recompiled before deployment.
Is there a way to specify string constants in such a way to avoid this recompilation requirement?
There are a couple of options I can think of:
One trick is to put configuration in a map keyed by hostname. At runtime, look up the configuration from the map, using window.location as a key. This will allow configuration to be baked into the Dart source, yet still allow different values to be specified for different environments.
If you want to be able to change your configuration after compilation, you can embed it as JSON within the HTML source, or load it via an HTTP request. (This isn't using a constant as asked, however, by definition it's not possible to change a constant after compile time)
Ok, so short answer is "You can't" - at the moment. But the Dart team are aware of this limitation, and are discussing it in dartlang as per the comment above.
I'm having some trouble merging the localization satellite assemblies into the plugin DLL for CRM2011.
Either that, or I don't know how to use the merged resources afterwards.
I create a few plugins and create a basic resource file (default - English) and one for a specific culture (at the time of writing it's for Polish localizations, but later I'll need to add French as well).
I make sure not to sign the assembly itself, as ILMerge will sign the finished assembly itself.
This is the command I use to merge the extra satellite assembly:
ilmerge /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /log:log.txt /keyfile:KeyFile.snk /out:Plugins.dll DynamicsCRM2011.Plugins.dll pl-PL\DynamicsCRM2011.Plugins.resources.dll
As you can see, the plugins are in .NET 4.0 and I've got the required .config file for ILMerge to use the required assemblies for merging.
The generated file appears fine, I can register it with CRM plugin-registrator, add new steps and so forth.
However, it will always use the default language. I've tried changing the System.Threading.Thread.CurrentThread.UICulture, but this didn't help. When I created a ResourceManager class and used GetString("ErrorMessage", new System.Globalization.CultureInfo("pl-PL")), I got an Exception that the specified ResourceManager doesn't know what to do with the specified culture.
I know of this question here. However, the posted solution seems to be an old one. The generated resource .cs files do not use a ComponentResourceManager. Also, parts of the code posted there have been marked as deprecated.
I'm not really sure what I'm am to do now, or how to further debug this, as I have very little experience when it comes to working with assemblies themselves. Please, help me get those satellite assemblies under control.
Update:
I've been working with sandbox plugins for a while now, and thus I no longer have access to things such as CurrentCulture (or at least I cannot change such things). I've tried tackling this problem once more: I've created a simple plugin which is fired when a new Account is saved. Nothing fancy. Here's the actual plugin code:
ResourceManager rm = new ResourceManager(typeof(Properties.Resources));
var s = rm.GetString("ErrorAlreadyPosted", new System.Globalization.CultureInfo("pl-PL"));
throw new InvalidPluginExecutionException(s);
The code no longer throws an exception about not being able to find the specified culture... also the code obviously throws an exception at the end, but the important thing is WHAT the exception message is. I'd expect it to be in Polish.
Alas, it is not. The string returned by GetString is still in English.
The command I used for ILmerge is the same as before, but with the /lib parameter specified so that I don't have to copy all the CRM SDK dlls...
Apparently it is not possible to read resources from with the context of a Plugin.
Read up on MSDN: http://msdn.microsoft.com/en-us/library/hh670609.aspx#BKMK_UseXMLWebResourcesAsLanguageResources
Quote: When a plug-in requires localized text, you can use an XML web resource to store the localized strings so the plug-in can access them when needed. The structure of the XML is your option, but you may want to follow the structure used by ASP.NET Resource (.resx) files to create separate XML web resources for each language. For example, the following is an XML web resource named localizedString.en_US that follows the pattern used by .resx files.
This is all I know so far - have yet to build my own solution for localization of a crm plugin.
If you use a reflector tool to look at the generated assembly, do you see your resource(s) embedded correctly? You may be experiencing the bug as outlined in the link you posted.
Try setting Thread.CurrentThread.CurrentUICulture and\or Thread.CurrentThread.CurrentCulture.
Also try hooking into the AppDomain.CurrentDomain.AssemblyLoad and\or AppDomain.CurrentDomain.AssemblyResolve to debug which assemblies are being attempted to load and from where. You might need to customize their behavior so that instead of loading an external assembly to load an internal resource instead.
You can try embedding project references as resources instead of using ilmerge as well.
See this: http://bartlomiej.net/dotnet/embeded-assembies-into-an-executable/
The way we eventually handled this is by adding the localization XML files (generated by Visual Studio) as CRM resources, and created a bit of custom code which seeks the appropriate resource and then seeks the localization text inside.
It's, obviously, not as simple as just using the generated C# localization class, and requires some prep work. However, with that prep-work in place and with using nameof it's now almost as simple as the aforementioned resource classes.