I have two machines with different cultures where the format mm/dd/yyyy is successfully parsed by Specflow (it's a step argument) in one but fails in the other.
I want my tests to be culture independent. So how to configure Specflow to use CultureInfo.InvariantCulture for parsing dates ?
Well, as nobody answered this. My solution for the problem was to edit the App.config file and add <bindingCulture name="en-US" /> in the <specflow> config section.
This forces Specflow, on both machines, to correctly parse MM/dd/yyyy date format.
For those looking for a .NET Core answer, you need to add a specflow.json file, set to Copy always or Copy if newer, to your project.
{
"bindingCulture": "en-US"
}
Related
I want to get current time in GMT+6 but can not make it work. what is the correct format to pass the timezone?
I've tried the followings -
[[${#dates.createNowForTimeZone('ASIA/DHAKA')}]]
[[${#dates.createNowForTimeZone("ASIA/DHAKA")}]]
[[${#dates.createNowForTimeZone('GMT+6')}]]
[[${#dates.createNowForTimeZone("GMT+6")}]]
But, all give the time in EDT.
UPDATE November 2022
Thymeleaf version 3.1 now includes built-in support for java.time:
The thymeleaf-extras-java8time extras module has been integrated into the Thymeleaf core: the #temporals expression utility object is now always available.
You no longer need to add the extra JAR mentioned below, for Thyeleaf 3.1 onwards.
(Spring Boot 3.0 uses Thymeleaf 3.1, if you are using that.)
Thymeleaf 3.0 and earlier
I recommend you use the Thymeleaf "extras" library for handling Java 8's java.time classes, and avoid anything related to the old and flawed java.util.Date class.
The library:
Thymeleaf - Module for Java 8 Time API compatibility
If you are using Maven, you can add it to your project using the following dependency:
<dependency>
<groupId>org.thymeleaf.extras</groupId>
<artifactId>thymeleaf-extras-java8time</artifactId>
<version>3.0.4.RELEASE</version>
</dependency>
Otherwise you can download the JARs manually from here.
Once you have installed the new JAR, you can use this:
${#temporals.createNowForTimeZone(zoneId)} // return a instance of java.time.ZonedDateTime
For example, as follows:
<div th:text="${#temporals.createNowForTimeZone('Asia/Dhaka')}"></div>
Or, using the syntax in your question, as follows:
[[${#temporals.createNowForTimeZone('Asia/Dhaka')}]]
Example output:
2022-05-19T18:57:32.190245400+06:00[Asia/Dhaka]
That was generated for the target timezone, when my local datetime was Thu May 19 08:57:32 EDT 2022.
Note about zone IDs:
You can read about valid zone IDs here. In your case, you need to be careful to match the exact case of the ID text - so it has to be Asia/Dhaka - not ASIA/DHAKA.
See also Where is the official list of zone names for java.time?
Note about formatting
There is a chance that you are going to want to format the date string, in which case take a look at the various #temporals.format() functions listed here.
But you may also want to consider formatting the string in Java, to keep your Thymeleaf template less cluttered.
I am using FME Workbench 2018.1.0.1 in Windows 10. I am inputting a kmz file. The only parameter I am reading from it is PLACEMARK because I see no reason to read the others. I need to copy format attributes kml_name and kml_description to NAME and CAPACITY, respectively. I don't see in the AttributeCopier transformer where I can do this. Its Import Wizard does not seem to be made to do this.
You have to expose them first. Double-click on your feature type (Placemark) and go to the Format Attributes tab. There you can select the format attributes you want to expose so you can use them after in downstream transformers.
There are some properties that I have in the default generated application.yml file in Grails 3. Take for example this property
test:
network:
path: '/home/cool/testing_data'
Now, the part that I want to do is change this property when I invoke the build script, so that it is different for the various OS that it might be executed on. I.e: On windows, that path should be 'E:/shared/testing_data', and on solaris, something different.
Using this post here, I can conclude that I can identify which OS I am currently on, so that I can potentially make some changes. Ex:
import org.apache.tools.ant.taskdefs.condition.Os
task checkWin() << {
if (Os.isFamily(Os.FAMILY_WINDOWS)) {
// it is windows, lets change the path to not be linux like
}
}
So my question is, using gradle or any other means as necessary, can I change the properties in application.yml file to accommodate the different OS systems that the application might be deployed on? I am considering reading the application.yml file line by line and doing a string replacement, but I will resort to this only if there are no cleaner solutions.
Maybe am I using the wrong tool to solve this problem as is, so a good question to ask is, is there an easier way that I am missing here, possibly a similar approach to different "environments" like :test, dev, prod, for operating systems, already built into the core functionality of grails that I can re-use?
Just create application.groovy file in the same folder as application.yml is. In groovy file you can use any script to set value of properties.
For example add this line to application.groovy file (also remove option from yml):
test.network.path = Os.isFamily(Os.FAMILY_WINDOWS) ? 'd:\something' : '/home/something'
I am converting DITA to XLIFF. In my technical solution I have to specialize (modify) xliff-core-1.2-strict.xsd to accommodate few DITA attributes. It means some attributes will go along with "g" tag. For Example:
<g id="00001" newAtt="this is new attribute" xid="009"/>
From the translation side I am not sure how it will work, so my questions:
Is it general practice that LSPs will get different flavor of XLIFF XSDs from different companies?
And is it possible for them to use it in their XLIFF editor by updating updated XLIFF XSD? I tried to explore “Transolution” but did not find any place where to place modified XSD.
Please let me know if you have any thought on this.
Thanks.
Here are my answers to your two questions:
I work for an LSP and I've seen all sorts and flavors of Xliff. Most of them try to stick to OASIS 1.2 transitional schema. Some of TMS/CAT producers added their own extensions. These producers normally provide an XSD so you can validate their Xliffs by adding that XSD to OASIS schema; e.g. SDL extensions to 1.2. When I'm customizing Xliff for a client, I normally do namespaces and provide a simple additional XSD; e.g.:
<trans-unit id="0" translate="yes" resname="msg_foo">
<superduper:uri>http://foo.bar/iJKLM9</superduper:uri>
<source>This is supposed to be a <superduper:g id="00001" newAtt="this is new attribute" xid="009"/> example.</source>
<target state="new"></target>
</trans-unit>
Most of the TMS/CAT tools are very basic (and closed) when it comes to their Xliff filters (or any of their filters for that matter) and I'm sorta kinda sure that they ignore your customized XSD.
Transolution is a very nice tool and my favorite Open Source translation tool. Unfortunately it's been long abandoned and has plenty of defects and shortcomings.
Anyway, if you provide a sample file, I can tell you what happens to non-conforming tags when it's imported into one of common, major CAT tools.
One final note; <g> seems to be retired in Xliff 2.0.
Forget about Transolution for one thing. I would try it with Trados, MemoQ or MemSource. Those are some of the big tools used in the translation business.
Personally I never got an XLIFF with a XSD, nor do I think Trados can handle it.
What do you need to change in the XLIFF?
In Delphi there is an option VersionInfo->Language->Locale ID when viewing project properties.
I was wandering how to set such property for a program being compiled under Free Pascal.
Any solution is welcome: command line argument or preprocessor directive such as {$key value}; equivalent to Delphi.
If you can build your projects using *.lpi files then I would try to add the following into your project's Project.lpi file. In the following snippet is shown how to set the project's locale ID (for Windows platform) to 0405 (Czech).
<?xml version="1.0"?>
<CONFIG>
<ProjectOptions>
...
<VersionInfo>
<UseVersionInfo Value="True"/>
<Language Value="0405"/>
<StringTable ProductVersion=""/>
</VersionInfo>
...
</ProjectOptions>
...
</CONFIG>
Or if you are using Lazarus IDE then you might use to Delphi very similar settings tab which you can open from Project / Project Options ... and as in Delphi go to Version Info where is the Language selection combo box available if you include the version info into the project.
Not 100% sure this will work, feel free to vote me down if this doesn't work.
Lazarus will inherit the locale settings it starts with.
You can set the locale info prior to starting Lazarus in Linux/OS X using the command line:
export LC_CTYPE="pt_BR"
export LANG="pt_BR"
export LANGUAGE="pt_BR"
./lazarus
Your compiled application should inherit these settings.
The answer is inspired by this workaround to an error has since been fixed.
I recommend you have a look at the fpc forum as well and ask the question there.
Don't forget it include details like the platform (Linux/Windows/OS X) and the exact version of FPC and Lazarus you are using as well as the actual Locale that you want.
Better answer
From: http://forum.lazarus.freepascal.org/index.php/topic,5924.0.html
Finally, I managed to find a simple and effective way to make my application localizeable. It uses just one unit and no code.
1. Add unit "defaulttranslator" to your uses list.
2. Enable "i18n" in "Project Options" and set "PO output directory" to "locale" or "languages". You can put translation files right into application folder, but that would just make a mess. Don't forget to create an appropriate folder.
3. Add components to the form. If you already have all components on your form, you'll have to move it a little bit, so it's modified.
4. Save your project.
5. Now there should be .po files in your "locale" or "languages" folder. For different languages files should be copied and renamed like so "project1.XX.po", where XX is language code (e.g. "en", "de", etc.).
6. Translate .po files with translation software, and generate .mo files. I suggest to use POEdit.
7. Run your application, and the translation to be used will be chosen by your regional locale settings. If you need to test other language - just start your application with following command line parameters - "-l XX" or "-lang XX", where XX is a language code.
This method is not very versatile, but it translates resource strings and LCL component properties.