For my automated tests, everything works fine, except only when it is in English, and this script needs to be able to run for Spanish versions of the same application too. I am not even sure if this is possible, but is there some way of making Ranorex do some sort of translations or some sort?
Currently, validation doesn't work because obviously the text is in a different language, how can I get around this? If it is even possible.
Usually, when testing an application which can be represented in different languages I would suggest using language independent properties in the RanorexPath (for example an automation id if available).
There are similar questions discussed in the Ranorex forum.
http://www.ranorex.com/forum/nls-testing-local-language-testing-t8438.html
http://www.ranorex.com/forum/localized-t3725.html#p15532
I hope that helps.
I have the exact same issue, and in fact, the displayed message/title is sometimes part of what I want to check depending on the chosen language.
What I did:
My different languages are handled through an xml file
the detection of my UI elements may be based on title (but I prefer unique ID when possible, like user1982826 said), in such a
case, I make that title a variable through XSpy.
In a code collection, I created a method that will initialize those
variables depending on the expected language (I'm using xdocument to
parse my xml)
Then, I call that method at the beginning of the recordings needing those variables (don't forget to bind them).
It's not perfect (I need to call that method multiple times for the moment), but ranorex support pointed me that using databinding from supported external source should do the trick. In my case, I should be able to trasnform my xml in a CSV file at the very beginning of my testsuit, and then use databinding on that file with the very same variables I created: data-driven-testing
Don't know if it's helping, it probably depends on how you handle the different languages of your application...
Also you can build your validations around different languages. Basically you'd just set a flag as a global parameter or a parameter that's held in the Program.cs-s Main method.
So if flag is set to "Spanish" it would do the spanish validations and if "English" the same would apply. You'd just have to capsulate the validations correctly in an if/else statements with userCode modules.
Related
I'm setting up a new iOS project and wondering if I should use a Localizable.strings file to keep my strings even without planning to add support for other languages.
I've tried using struct to keep my strings before but I am wondering if this is a good practice. Using Localizable.strings will also work well on the library R.swift, another reason why I am struggling to choose a strategy.
There is no "best practice" in this case. There are practices and some may be a bit more appropriate for your case than others.
You are saying that you are not planning to add support for other languages but it seems like you want to be prepared for it if you change your mind. So first thing is to ask yourself what is the actual problem you are looking solution for. I would say the problem is the overhead you get once app is already out and you need to hunt all the strings you have used in your app and wrap them into NSLocalizedString. This usually includes endless testing and you will still in the end most likely forget to localize at least some strings.
You can from beginning start wrapping things into NSLocalizedString which will in the end help you extract all the strings using native tools from your code. The problem then are still Storyboards; not as much extracting strings from storyboard but removing those default texts you have no plan to translate (Like "Name" will actually be some name and should not be translated). So in my experience this is a half solution.
To solve the Storyboard issue there should be a tool (I can't remember which, maybe some other CocoaPod) which enables you to ignore views that should not be translated. So in this case you need to use 2 things; NSLocalizedString and ignoring untranslatable items in IB.
As you already put it nicely you can use R.Swift to get strings directly from your strings file. This is very neat but also extremely distracting as you develop. Doing so you are forcing developer to first enter a text in strings file before he can use it. Personally I hate that. Also this can be a problem with multiple developers being in conflict. Not to mention this hasn't nearly fixed your issue with Storyboards.
Creating a separate structure system to hold all the strings does work pretty nicely. You don't have to hunt down all of the strings in your code and you don't need to jump to strings file (going to another source is much more pleasant when developing since you can navigate to it very easily). You do also preserve a good structure, assuming you maintain it like label.text = Strings.Settings.User.firstNamePlaceholder which helps you to easily find strings you need or are deprecated. You can remove whole screens with great ease. But it still is an overhead for developer plus you still have an issue that now you need to drag all the outlets from storyboard to set the localized strings to them.
Doing this procedure you can in the end choose to use NSLocalizedString directly or to use R.Swift. In fact you can just use nothing and you will still not have much overtime switching to any of the two (again assuming that hunting down those strings in the code takes most of the time).
Personally I would go with nothing at all or go with creating a custom structure system which then uses nothing but just returns raw strings. But this all really depends on what size is your project of, what type of project, how many things are in Storyboards... It also depends on when you expect to have more resources so you either spend more time now and don't bother later or you simply do it simplest now prepare for a lot of work when localization is indeed needed (hopefully when that happens it is one of the "sweet" problems because it means you have tons of users).
I have several sets of values (factory setting, user setting...) for a structure of variables and these values are saved in a binary file. So when I want to apply certain setting I just load the specific file containing desired values and these values are applied to the variables accordingly to the structure. This works fine when the structure of variables doesn't change.
I can't figure out how to do it when I add a variable but need to retain the values of the rest (when a structure in a program changes, I need to change the files so that they would contain the new values accordingly to the new structure and at the same time keep the old ones).
I'm using a PLC system that is written in ST language. But I'm looking for some overall approach for solving this issue.
Thank you.
This is not an easy task to provide a solution that is generic and works with different plc platforms. There are many different ways to accomplish this depending on the system/interface you actually want to use e.g. PLC Source Code / OPC / ADS / MODBUS / special functions, addins from the vendor and there are some more possibilities e.g. language features on the PLC. I wrote three solutions to this with C#/ST(with OOP Extensions) and ADS/OPC communication, one with source code parsing first in C#, the other with automatic generation from PLC side and another with an automatic registration system of the parameters with an EntityFramework compatible Database as ParameterStore. If you don't want to invest too much time in this you should try out the parameter management systems that are provided by your plc vendor and live by those restrictions.
I'm looking for an alternative to FileMaker Pro. I've been playing with a trial for a week now.
I'm looking for a rapid application development platform for small relational databases to run on iOS and OS X
Things I like about FM
Can make reasonable looking layouts quite quickly.
Can access the database from an iPad with Filemaker Go.
Things I don't like about FM
EVERYTHING takes a half a dozen clicks. In particular constructing a script with mouse clicks is painful.
The number of modal dialog boxes is astounding. It is routine to have them layered 3 deep.
Syntax is verbose. Set Variable [ $name Value:value ] Some of the examples start to look like excel formulas. (Excel is a write only language....) Or COBOL.
Near as I can figure variable scope is either local or global. If a script calls a script, you must call it with any local variables you want it to have access to.
Debugging is very difficult in the FM Pro version.
Doesn't seem to be any provision for building a library of functions in a single file.
No clear and obvious guide to how to document your database so that it can be maintained.
No clear and obvious way to print out all your scripts.
No clear and obvious way to print out a calling tree/dependency tree.
No clear guide to best practices.
The short answer is: Despite it's shortcomings (and I'll admit it has many), FileMaker is still the best rapid-development platform for OS X and iOS (and Windows, for that matter). The closest second-place (for OS X/iOS) I can think of would be Cocoa/Cocoa Touch with Core Data with Ruby on Rails for a web interface a distant third.
Having said that, I can offer a few tips for some of your complaints:
If you're a keyboard-centric person like myself, turn on Full Keyboard Access (in the Keyboard System Preference within the Shortcuts tab). This will allow you to tab through all of the controls, such as buttons, which makes it much easier to select deep dialog options from the keyboard. For example, when building a script, you can use the tab key to focus on the list of script steps, then type a few letters of the step you want, which will highlight it, and press return, which will add it to the script. Then, while a script step in the script is highlighted, you can use Ctrl-Up and Ctrl-Down to move the step up and down in the execution order.
Script variables, both local and global, can be set within any calculation. For example, if you're capturing a primary key value to a local variable and you already have an If script step, you can do the capture within the If script step.
If[ Let( [ $record_id = Table::ID ]; not IsEmpty( $record_id ) ) ]
Similarly, if you have a number of Set Variable script steps in a row, you can combine them into one:
Set Variable[ $? Value:Let( [ $var1 = 1; $var2 = "two" ] ) "" ]
This sets the $? variable to an empty string, but has the side effect of also setting $var1 and $var2.
You're correct that variables are either local to a script (or calculation) or global to the file. If you want to share information between scripts, parameters are the solution. For my personal solution for sending multiple parameters to a script, read my article on Multiple FileMaker Script Parameters.
If you're going to do any amount of custom development with FileMaker, you really want to get FileMaker Pro Advanced, which, inaddition to a step-level debugger, offers the ability to create custom menus and, my personal favorite, custom functions. Using custom functions (which can easily be brought from one file to another), you can built a complex library of functions.
To print out all of your scripts, open Manage Scripts, select all of the scripts with Cmd-A and click the print button on the bottom right of the window.
For script dependencies, look into BaseElements, a FileMaker-based solution for documenting FileMaker systems.
While there's no standard "best practices" across the board, and because of how FileMaker organizes its objects, documentation is often found in various places (script comments, calculation comments, field comments), there are many ways to build a system in FileMaker so that you increase its maintainability. Unlike Objective-C or PHP, where you can be fairly certain where the comment for something will be (either in the declaration or at its first use), FileMaker is more flexible. The important idea behind "best practices" and documentation, in my opinion, is consistency. If you comment a field by using the field comments, always comment fields that way, don't comment calculation fields within the calculation or use dummy validation to put comments in a calculation there.
If you're looking for one guide (but not the only guide) for best practices, check out FileMaker Coding Standards. I use some of those guidelines, and others are my own that have evolved over time.
Finally, if you're looking for generally great material on how to get the most from FileMaker, check out FileMaker Magazine, published by one of the people involved with the FileMaker Coding Standards site.
The truth is, if you're coming from some more conventional development platform, FileMaker is going to take a bit of getting used to. I've been using it for over 20 years, so I'll admit it's probably difficult for me to completely empathize with that situation. But if you give it a bit of a chance, I think you'll find that there's no other platform available that can build complex database systems for OS X and iOS so quickly.
Filemaker takes a lot of getting used to, it's very different to SQL or any of the mainstream taught languages so if you have done some training you will need to re-think how to get to the same end goal.
If you are serious about it then get Filemaker Pro Advanced v14 and that should fix some of your GUI editing issues and join developer.filemaker.com and do the training course that you can download from there.
Once doing that and getting some experience you will find Filemaker is very RAD. Also there IS a way to get around any shortcomings, everything is possible in Filemaker.
As for passing multiple parameters to a script a quick and easy way to do it for 99.5% of cases is to do this:
Calling the script - In the parameters box separate your parameters with a carraige return like so: "parameter 1" & "¶" & "parameter 2" & "¶" & "parameter 3" etc.
In your receiving script use GetValue(get(scriptparameter),1) for parameter 1, 2 for 2, etc.
This technique won't work when you are trying to pass text with carraige returns but that is the exception.
I am looking for a good way to translate an excisting Sitecore installation (English language is available) to 4 other languages (Russian , Chinese, Portuguese etc.) A dedicated translation company will translate all texts we deliver to the specified languages, but I'm curious on how other companies set this up. I thought about just exporting all Sitecore items which have to be translated using the Database language Export function in Sitecore and having the translation company edit those files. By just replacing the language tags in the XML we should be able to import this file as the newly created other language, however I'm affraid that this XML structure will be totally useless for a translation company and that they will drown in the codes inside this XML. How can we efficiently do this? Is there any other way then just giving those translation people access to the Sitecore environment and having them edit the languages here? Any Shared Source Module to achieve this? I still have alot of questions, is there anyone with some experience in achieving this?
Your primary options are either the language export/import functionality (as you mention), or a workflow-based solution that integrates with your translation agency's Translation Management System (if they have one -- hopefully they do).
The former is better for the initial translation. Typically, your agency should be able to handle translation of content within XML files. A good one can. If you create all needed language versions beforehand and copy english content into them, it will make the files easier to work with as they'll have tags for the new languages in them already. I've seen the creation of these layers done with Revolver (http://www.codeflood.net/revolver/) but could also be done with custom code or workflow.
For ongoing maintenance of your translated content, you'll probably want to integrate through workflow. Clay Tablet Technologies (http://www.clay-tablet.com/) have a middleware component w/ Sitecore integration that can make this easier, depending on your translation agency. You can also do your own workflow-based integration, with workflow commands that allow your users to send content for translation. Then you'd need some sort of listener that pulls the translated content back in, and continues the workflow.
Hope this helps!
You could also check out Lionbrdige (http://en-us.lionbridge.com/sitecore-and-lionbridge-announce-partnership-to-help-companies-thrive-across-borders.htm) as a solution.
From my own experience our customers normally use the Sitecore import/export function as a first step and then use Lionbridge or Clay Tablet as a service.
One important thing to think about with translations is the ongoing work. The initial translation is rather simple, but the second and so on might be more troublesome. What if different changes has been made in different languages. If local changes were made in the content for sat the french version you couldn´t just send the English version (second translate then) since you would also have to accomodate for the regional changes in the content.
Having worked with literally dozens of Sitecore clients worldwide — and helped get content to and from all the largest, and many smaller translation firms —, I can attest to the ineffeciency of trying to do translation in situ, that is in Sitecore. I liken it to asking an electrician to come over and rewire your house, but as they reach for their toolbox from the truck you tell them, "Nope — you need to do it by hand".
The very best way to manage anything more than a page or two of content for translation is to export it seamlessly. Deliver it to the LSP in a proper format (XML or XLIFF) and, when possible, auto import it to their TMS. Once translated, the content should then flow seamlessly back into Sitecore.
You can code this yourself — but the pitfalls are non-trivial just on the Sitecore side. (If you want intuitive UI's, scalability, and all the features that meet the needs of translation). Let alone the challenges of connecting to the systems LSP's use. (For example, who here knows the relative merits/risks of using SLD's Nexus connector versus their CTA for connecting to TMS?)
As kindly mentioned above, there are commecially available solutions that meet all these needs and more. So if you've got even a modest amount of content — and want to send that to any translation provider of your choice — I'd be happy to discuss how we can help.
The main issue with translation isn't technical at all, the XML export is a simple enough format and all agencies should be able to deal with it with no porblems. as others have suggested, maintenance after the initial translation is slightly more problematic but they also point to tools to achieve this.
The main issue we've found with translation is actually linguistic: how to achieve consistency of phrasing and that matches the original but is sufficiently adjusted to local requirements. Translation companies usually have software to aid this - libraries of of the phrases they translate etc. - working with an exported XML file doesn't provide the context of seeing content in situ. A particular item may be translated correctly and the site consistently, but as each page may be built from multiple items there can easily be conflicts between content as presented.
That makes working with the Sitecore backend (maybe with field security settings to limit ) or in the page editor (possibly pre filling fields with English values) a viable idea.
I believe several of us have already worked on a project where not only the UI, but also data has to be supported in different languages. Such as - being able to provide and store a translation for what I'm writing here, for instance.
What's more, I also believe several of us have some time-triggered events (such as when expiring membership access) where user location should be taken into account to calculate, like, midnight according to the right time-zone.
Finally there's also the need to support Right to Left user interfaces accoring to certain languages and the use of diferent encodings when reading submitted data files (parsing text and excel data, for instance)
Currently I'm storing all my translations for all my entities on a single table (not so pratical as it is very hard to find yourself when doing sql queries to look into a problem), setting UI translations mainly on satellite assemblies and not supporting neither time zones nor right to left design.
What are your experiences when dealing with these challenges?
[Edit]
I assume most people think that this level of multiculture requirement is just like building a huge project. As a matter of fact if you tihnk about an online survey where:
Answers will collected only until
midnight
Questionnaire definition and part of
the answers come from a text file
(in any language) as well as
translations
Questions and response options must
be displayed in several languages,
according to who is accessing it
Reports also have to be shown and
generated in several different
languages
As one can see, we do not have to go too far in an application to have this kind of requirements.
[Edit2]
Just found out my question is a duplicate
i18n in your projects
The first answer (when ordering by vote) is so compreheensive I have to get at least a part of it implemented someday.
Be very very cautious. From what you say about the i18n features you're trying to implement, I wonder if you're over-reaching.
Notice that the big boy (e.g. eBay, amazon.com, yahoo, bbc) web applications actually deliver separate apps in each language they want to support. Each of these web applications do consume a common core set of services. Don't be surprised if the business needs of two different countries that even speak the same language (e.g. UK & US) are different enough that you do need a separate app for each.
On the other hand, you might need to become like the next amazon.com. It's difficult to deliver a successful web application in one language, much less many. You should not be afraid to favor one user population (say, your Asian-language speakers) over others if this makes sense for your web app's business needs.
Go slow.
Think everything through, then really think about what you're doing again. Bear in mind that the more you add (like Right to Left) the longer your QA cycle will be.
The primary piece to your puzzle will be extensive use of interfaces on the code side, and either one data source that gets passed through a translator to whichever languages need to be supported, or separate data sources for each language.
The time issues can be handled by the interfaces, because presumably you will want things to function in the same fashion, but differ in the implementation details. To a large extent, a similar thought process can be applied to the creation of the interface when adjusting it to support differing languages. When you get down to it, skinning is exactly this, where the content being skinned is the interface, and the look/feel is the implementation.
Do what your users need. For instance, most programmer understand English, there is no sense to translate posts on this site. If many of your users need a translation, add a new table column with the language id, and another column to link a translated row to its original. If your target auditory contains the users from the Middle East, implement Right to Left. If time precision is critical up to an hour, add a time zone column to the user table, and so on.
If you're on *NIX, use gettext. Most languages I've used have some level of support; PHP's is pretty good, for instance.
I'll describe what has been done in my project (it wasn't my original architecture but I liked it anyways)
Providing Translation Support
Text which needs to be translated have been divided into three different categories:
Error text: Like errors which happen deep in the application business layer
UI Text: Text which is shown in the User interface (labels, buttons, grid titles, menus)
User-defined Text: text which needs to be translatable according to the final user's preferences (that is - the user creates a question in a survey and he can also create a translated version of that survey)
For each different cathegory the schema used to provide translation service is different - so that we have:
Error Text: A library with static functions which access resource files
UI Text: A "Helper" class which, linked to the view engine, provides translations from remote assemblies
User-defined Text: A table in the database which provides translations (according to typeID of the translated entity and object id) and is linked to the entity via a 1 x N relationship
I haven't, however, attacked the other obvious problems such as dealing with time zones, different layouts and picture translation (if this is really necessary). Does anyone have tackled this problem in a different way?
Has anyone ever tackled the other i18n problems?