I'm working on a multi-tenant application catering to customers in different countries. When displaying measurement results, the display labels measurement values need to be in different languages.
Labels for measurement values received in one tenant will only need to be translated to that tenant's language (we assume that the users will be patients or employers that understand the same language).
What is a good strategy for storing/displaying translated strings? Should I perform translation when storing the values and add a custom value in code.coding or is it better to translate existing code.coding.display values when rendering the view?
FHIR is silent on whether you should translate before storing or when returning data. Do consider the ramifications on digital signatures regardless of approach (anyone adding translations after the instance is signed will break the signature). There's a standard extension for conveying the language of a string and translations of the string - see http://www.hl7.org/fhir/extension-iso21090-st-language.html and http://www.hl7.org/fhir/extension-iso21090-st-translation.html. These work on any string in a FHIR instance.
Related
I am writing a multi-language dictionary app. When the user selects a language to use data from, that language should apply to every page until they select a different language. Ideally, the language should be part of the URL so that the address for the English word "double" and the French word "double" is different. It should also be possible to specify no language, so that "double" would display both the English and the French word. I will also want to filter the data on multiple fields at the same time, e.g. the word itself and the language.
I'm trying to fit this into the Laravel resource concept. The index view of Word should show all words filtered by the language, or not filtered if no language is specified. create should keep the language from index. store should just use the form data. The language can be included as a hidden field in the create view if it's been specified. show doesn't strict speaking need a language filter, but if the user then goes back to index, the filter will still need to be applied.
I started using routes, but that means I'll have to hard-code a route for every filter. I've also thought of using session data, but that means the URLs wouldn't include the filter. If the filters are appended as a query string how would Laravel access them? Is this a good solution?
I'm using Laravel 5.8. What's the best Laravel way to persist this type of data filter across views?
I have similar issues in many areas of our apps. We occasionally use Session for this, but generally find the most efficient and easiest way to solve this is to attach a database field to the user object.
If you are using any type of auth, Laravel is already going to boot the user object on every page view, thus the filter can be pulled with no extra calls to the database. If no language is specified, the \Auth::user()->current_lang_id will be null, and thus no filter would be applied. We typically use a relationship (e.g. 'currentLang()') which makes it easy for the user to see the language and can automate binding on the form.
The nice part of this, we've found, is that it individualizes it per user, and it 'remembers' the user's preferences between sessions in a simple way - no need to make dozens of routes or a special variable + logic on multiple routes because those routes include your filter. Instead, you can put your logic at the top of a base controller and be done with it.
Lastly - changing the language when it is a db field on the user is just standard, simple CRUD.
HTH
I am evaluating HippoCMS and am trying to model a schema of Venues. I want to model a document that has non-translatable features such as telephoneNumber and emailAddress, plus translatable features such as description.
How do I model this in HippoCMS? How do I ensure that the non-translated fields are shared between the different translations, to avoid each translated document having its own copy of a value. Obviously no matter which language you are reading a site in, the telephoneNumber shouldn't change.
The only way I have found for the moment is to create a document called Venue and another document called VenueTranslation. Venue would contain the telephoneNumber and VenueTranslation would contain its description and a link back to the Venue document. There would then be VenueTranslation documents for each language.
Is this the correct approach?
That could work, but you will run into usability issues. I'd say it depends on how many venues you plan to enter into the system, how many languages you are targeting, and, in the end, how keen are your CMS users to pick the right Venue document for every VenueTranslation corresponding to a language. I can see how this will quickly become error prone and cumbersome, but I don't have the numbers.
Regarding the final question, it's not correct nor incorrect: it's just that since the granularity of the translations in Hippo is at the document level and not at the field level, you have to do it this way. Your model makes sense but is not well supported in the CMS. This use case is trivial in a CMS that supports the notion of translatable field.
I am currently using APEX 4.0. I would like to make a validation that would apply for multiple fields in a form. For example, I want specific fields to only accept a Y or N, and they must be uppercase letters. As of now, I have one validation for each field. Is there a way to make a single validation that would apply to all these fields?
Creating Re-Usable Form Validations in Oracle Application Express (APEX)
This solution was developed on a Apex instance hosted on Oracle OTN (apex.oracle.com). This instance is currently at version 4.2.5, but the design elements discussed within this solution should still be compatible across the versions from 4.0.0 and 4.2.5.
The way you can approach your form design is not necessarily to catch exceptions through a validation step once the form has been completed and submitted.
Instead, simply consider limiting the choices that the user can choose in their input, and control how that input is interpreted once it is submitted as changes to your data table.
Pre-Validate By Defining Restrictive Value Choices
Here is an example of the OP requirement defined as a "Shared Component" through the "Application Builder" menu. Create a named LOV (list of values) with a static definition. Here, you can define the value pairs of:
DISPLAY, which is anything user friendly you want the user to see. Even if Y or N is pretty self-explanatory, explore other options such as spelling it out (such as: YES) or combining the real value with the display (such as: Y (Yes)).
RETURN VALUE, which is where you enforce what goes into your database. In this case, the uppercase, single character values mentioned in the OP requirements would go here.
This is what that LOV definition looks like:
APEX LOV (list of values) Design Screen
Eliminate Free-form Data Form Item Display Types
Following with the initial concept of a limiting LOV, convert all your form items to use display-types which use a "List of Values" definition pointing to your "Shared Component" (or Named LOV).
Use the SAME LOV definition for questions requiring the same input rules. Now the user has no way of changing the data values outside of the OP definition, and there is some flexibility to use more instructive/descriptive display values so that they are more likely to make the right selection as well.
This is an example of how a input form with the same input data types can accomplish this task with no additional validation:
Sample APEX Form Design with Reusable Input Restriction Rules
In this example, I experimented with a few form item styles, including
The standard text-box entry field. (Problematic without coupling it with additional validation logic).
Select-list entry items worked the best. See the discussion at the end of this solution for more explanation on choosing specifics such as specifying "null field values".
Radio group selection buttons work well to as they provide a visual layout of the valid form choices without additional drilling-down or scrolling.
All three options used the same LOV definition.
Examples of Data Input Using LOV Enforced Restrictions
After experimenting with different kinds of inputs, here's a few things that may be helpful depending on the situation or the deeper requirements of this OP or other readers.
DISPLAY EXTRA VALUES should be left as set to NO. This is the reason for restricting the input possibilities in the first place.
DISPLAY NULL VALUE is best as NO if all answers require a response. If NULL is possible, there is a useful third (defaulted) value that can be used for additional user-friendliness.
Sample Data Inputs and Values from the LOV Restricted Form
Notice that the free-text entry field presents additional problems with data quality without some other form of validation or checking. The other form fields provided accurate data input reflected through the target database table.
Some Closing Comments and Points for Further Study
This solution is only a partial one with respect to protecting information stored in a database table. It is not uncommon for lots of other systems, applications, programs, api's, etc. to also have access to change or add data to this back-end data source.
What if another group of developers independently created an api for managing data in the same table? Unless they read the documentation of the OP or examined existing data sets already present, their project team may not have designed an accurate interpretation of the rules which sit at this point, only on this particular APEX application.
Depending on how vulnerable your system is, it is also good practice to apply relevant safeguards, such as schema level table constraints (such as check constraints), Not Null constraints (where applicable) and even DEFAULT values settings (established by triggers or table default values).
From the Author...
Again, it isn't all necessary to go to this detail... if the input form of the Apex application offers only two choices: "SOUP" or "SALAD", it is unlikely that "BACON-ORANGE-CHICKEN" will pop up in the table after deploying the application into users' hands.
This kind of design approach skips a server round trip worth of I/O because the user already know what is on the menu at the initial page loading event.
Although the OP request is very simple and generic (Y for YES or N for NO), it presents a useful pattern for more complex input screening procedures that can happen even before the data is submitted.
Good Luck, All!
Onward.
We currently have a Web Forms set up for our website and are looking to slowly convert this to MVC. Currently we store translations in a database. our translation table contains columns for each language and a sort of title. which we can identify the translation with(The primary key)
But it gets more complex when we actually may have different clients wanting different words for the same bit of text.
E.g. one will want it to read - Delivery Costs
And the next may want it as - Delivery Prices
So we then have a second CustomTranslation datatable which will be the same as the translation but also have a client ID number in it. If the user logged in and it looking for the Identify of the translation as "DeliveryCost" it will check to see if there is a record in the CustomTranslation table it will use that OVER the standard Translation table.
After which it will then pick the appropriate language the users wants.
Basically I need to be able to have our website translate depending on the users settings. And as well as the company they work for (our client)
The general method of localization uses resource files but we need to really keep them in the database. This produces a second problem which is when you try to declare Propertry Display Names and Validation Messages these also need to ability to have different text and/or translations but generally it expects a Static field which we would not have.
Whats the best way to go about solving this complex localization issue?
Thanks in advance. Steve
Problem 1 - Having the resources in the database
Use the approach used in this article for extending the standard resources into the database.
Problem 2 - Having custom localization per customer
No problem, the standard .net approach supports localization including a region or customer, just use i.e. en-US, en-US-Customer1, en-US-Customer2, etc.
I am investigating for a tool that allows a user to perform in a user friendly way queries to database for extracting datas and creating reports.
Primary requirement is that we can't know queries users are going to do. So we need to design a flexible UI allowing them to specify in a non technical way.
My question is: do you know any tool that does something similar? Have you some inspiring user interface?
For inspiration, there are five established approaches I know of:
Attribute List. For a given table, you (the designer) provide a list all attributes for which the user specifies the query attribute value. Sometimes the user also specifies the operators (e.g., Like, <, >, etc.); otherwise it’s fixed by you depending on the data type (strings use Like, numeric and date attributes use ranges). All criteria between attributes are combined by a logical AND. If you allow the user to list values for a single attribute, they are joined by a logical OR. Users generally assume that a blank attribute value implies that that attribute is not included in the criteria. Generally, you specify the table(s) that are likely to be of primary interest to users and hard-wire the Joins. Because the tables, joins, and Boolean possibilities are fixed, this has limited ad hoc flexibility, but for most cases it’s more than adequate. It’s the most common approach out there.
Query by Example. Users select the table(s) they want to query and you provide an empty multi-record form (e.g., grid) that includes all the attributes of the joined tables; that is, an empty query result (in some cases, the user selects the attributes to show too). The user completes the attribute values as if they were example records, where a blank attribute is assumed to vary. Thus, if Priority and Status values are entered for the same record, their attributes are combined by a logical AND. If they are entered on different records, they are combined by a logical OR. In some cases, the user may also specify operators for each attribute (e.g., to specify ranges of values). This provides a very high level of flexibility and seems to be relatively intuitive for users.
Diagrammatic Query. Tiziana Cararci’s Query by Diagram approach allows users to specify sophisticated Joins and Boolean by graphically manipulating an entity-relationship diagram. For more details, Google for:
Catarci T & Santucci G (1995). Diagrammatic Vs Textual Query Languages: A Comparative Experiment. Proceedings of the IFIP Work Group. 2.6 Working Conference on Visual Databases, (March).
Catarci T, Costabile M F, Levialdi S, & Batini C. (1997). Visual Query Systems: Analysis and Comparison. Journal of Visual Languages and Computing, 8(2), 215-260, (June).
Graphic Filter Query. Ben Shneiderman’s Filter Flow approach allows users to specify sophisticated Boolean by constructing visual networks of operators and criteria, leveraging a plumbing or electrical metaphor. Google for:
Shneiderman B (1991). Visual User Interfaces for Information Exploration. Proceeding of the 54th Annual Meeting of The American Society for Information Sciences, 28 (Washington, DC, October).
Murray NS, Paton NW, Goble CA, Bryce J (2000). Kaleidoquery: A flow-based visual language and its evaluation. Journal of Visual Languages & Computing, 11(2), 151-189 (April).
Natural Language Query There’s been a lot of effort to try to parse natural language or semi-natural language into a structured query, but it hasn’t had much success, partly due to the ambiguity of natural language (e.g., in “Commission income of all salespersons assigned to Great Britain and Ireland,” the “and” could be interpreted as either a logical OR or AND). You could try returning multiple results (one for each interpretation) for the user to choose (sort of like Google). This approach may be adequate for unskilled users and for when a sufficing rather than perfectly correct result is sufficient.
Many modern web dev frameworks let you make scaffolds from your daabases. which are simple web pages containing crud operations. where you can search and browse related records.
I personally have seen Linq2SQL for asp and Ruby on rails doing that. there are many more
"user friendly" and "non technical way" sounds like Ad-Hoc reporting. In this case you can take a look in this Ad-Hoc reporting demo. But there are many other Ad-Hoc reporting tools.