TYPO3 8.7.x, Powermail 6.0.0
I'd like to override the receiver based on two subjects they can select.
Now I know that this works just fine:
[globalString = GP:tx_powermail_pi1|field|konsilbereich = 5]
But this does not seem to work:
[globalString = GP:tx_powermail_pi1|field|konsilbereich = "Some phrase"]
I read that some workarounds were to have a hidden field that's been filled by Javascript upon a users selection and instead of the actual field, the hidden field gets submitted. But that is not an option for us.
I checked the docs as well as many support forums but could not find a good answer to this.
Is this not possible, or if, how would I accomplish that I can use an actual string within the comparison?
The problem is a comparisation with a string in TypoScript conditions. Strings could have space, special characters or umlauts. That's why TypoScript works best with integers.
Two possibilities come into my mind for your case:
1) Building an own conditition is quite simple in TYPO3 (see https://docs.typo3.org/typo3cms/TyposcriptReference/latest/Conditions/Reference.html#custom-conditions for an easy example)
2) Use an integer together with GP: - but then I would use a selectbox with a text as label and a number as value
Related
I'm aware that there are some languages that writes the order of some characters differently than the common latin languages. E.g.: a percentage number in English would be like "100%", while in Persian it would be "/100" (the symbol comes before the number).
Question: how to consider that in the Qt internationalization system in an intelligent way?
I first thought about this code:
myLabel->setText(tr("%1%2").arg(value).arg(tr("%")));
So what would happen is that, in the Qt Linguist, the translator would change the order of the replacement fields:
%1%2 -> in Persian translation -> %2%1
I checked that in my code and I found out that while in the normal (English) translation everything was fine, when I changed to the file containing the performed translation, a bug would occur: the number to be shown was never complete having one less number that what I had written. So e.g. if I chose "99%", it would show "%9", and if I set only "9%", I would have just "%".
The problem disappeared when I put a space between %1 and %2 both in the source code as well as in the translation (%2 %1). Since ISO xxxxx says that the % should be placed with a space between it and the correspondent number, no problem for this specific situation. But what If I wanted to have both symbols without a space between each other? How should it be done?
I confirm that the problem you described exists. However I would solve this problem in the following way:
QString sPer = QString("%%1").arg(value); // %99
QString sEng = QString("%1%").arg(value); // 99%
So that
%1% -> in Persian translation -> %%1
Put the percentage inside the string to translate, something like
myLabel->setText(tr("%%1").arg(value))
even better, I think I would add a disambiguation string (Qt "old style" comment)
myLabel->setText(tr("%%1", "Show the number with a percentage").arg(value))
or maybe a new style translation comment like this
//: Show the number with a percentage
myLabel->setText(tr("%%1").arg(value))
Translator comments have issues of their own, you might be better off using a Qt disambiguation string like the preceding example.
Putting a disambiguation string (or a translator comment) will let your translator know what they are translating...
Let the translators decide where they want to put the percentage, don't try to handle it in the code as somebody else suggested, it is not scalable, you can't start handling this in the code like that, what if you need to use another character or formatting for another language?
It might even be possible that Qt might have calls to handle number formatting but I can't seem to find them at the moment and I am not fully sure how we handle them in the Qt application I work on...
If putting a % alone doesn't work, try to precede it with \, it might be necessary to escape it, I am not sure...
I'm working on a Spring MVC Project and ran into a problem with the internationalization in forms, especially the number formatting.
I already use fmt:formatNumber to format the numbers according to the current selected locale.
<fmt:formatNumber value="${object[field]}"/>
Like this, number formatting works well when I display numbers. But how about the forms?
At the moment, the input fields that are supposed to receive float values are prefilled with 0.0 and expect me to use "." as decimal separator, no matter what locale is selected. Values containing "," are refused by the server (...can not convert String to required type float...).
How can I make my input fields use and accept the appropriate number format as well?
Did you have a look at #NumberFormat? If you annotate the property the input field is bound to, this should result in the proper formatting. Something like:
#NumberFormat(style = Style.NUMBER)
private BigDecimal something;
This style is the "general-purpose number format for the current locale". I guess, the current locale is determined threadwise from the LocaleContextHolder.
Your app needs to be annotation-driven, also see the section "Annotation-driven Formatting" in the docs.
You might want to take a look at the DecimalFormatSymbols as suggested in this answer.
I have been fruitlessly searching for a solution for the following problem in Drupal.
Making a selection in a multiple-select field (i.e. a list of checkboxes) will yield an "Illegal Choice Detected" error if any of the choices contain apostrophes. This problem is referenced here. This field exists within registration and is not generated through either webforms or CCK.
Does anyone have any exact solution in mind, i.e. specific code to add to modules, or making particular updates?
Try to use one of two php functions to generate strings:
htmlspecialchars
htmlentities
My application is currently displaying negative numbers as -1. The users have changed the requirements (just for a change!) and now we will have to display the numbers as (1).
Can I enable that for the whole application say changing the web.config or even the app's CultureInfo ? Is there any side effect of doing that since we have lots of pages that contain number validators ?
Thanks !
For currency it is really easy:
String.Format("{0:C}", value)
This will use the culture info for the system.
For normal numbers being data bound, use Mark Glorie's sample.
MSDN Article
I'd use String formatting. Making a change to the application's configuration to satisfy a UI requirement is heavy-handed. SteveX wrote a great blog post about String formatting. It's also compatible with markup (aspx) instead of only relevant in code.
From his post:
String.Format(”{0:$#,##0.00;($#,##0.00);Zero}”, value);
This will output “$1,240.00″ if passed 1243.50. It will output the
same format but in parentheses if the number is negative, and will
output the string “Zero” if the number is zero.
Which isn't exactly what you want, but it's close.
Check this..
http://msdn.microsoft.com/en-us/library/91fwbcsb.aspx
Converts the string representation of a number in a specified style to its Decimal equivalent.
I've got the following page bookmarked for doing string formatting: http://idunno.org/archive/2004/14/01/122.aspx
About halfway down, it gives the answer:
String.Format("{0:£#,##0.00;(£#,##0.00);Nothing}", value);
To answer your other question, I wouldn't modify the app.config to make it global, for reasons given in the other answers.
String.Format(”{0:f;(f);0”, -1);
This works.
DataFormatString="{0:c0}"
Nagative amounts in paranthesis
Thousand separater - comma
$ symbol in front
You could always write your own custom ToString() method as an extension method, but like you mention, using CultureInfo is probably better. Take a look here:
http://msdn.microsoft.com/en-us/library/system.globalization.numberformatinfo.numbernegativepattern.aspx
Are you displaying your data in Gridview/Datagrids? If so then formatting can be applied per bound-column, something like:
<asp:BoundField DataFormatString="{##;(##)}"/>
This only works with integers however...
An HTTP GET query string is a ordered sequence of key/value pairs:
?spam=eggs&spam=ham&foo=bar
Is, with certain semantics, equivalent to the following dictionary:
{'spam': ['eggs', 'ham'], 'foo': bar}
This happens to work well for boolean properties of that page being requested:
?expand=1&expand=2&highlight=7&highlight=9
{'expand': [1, 2], 'highlight': [7, 9]}
If you want to stop expanding the element with id 2, just pop it out of the expand value and urlencode the query string again. However, if you've got a more modal property (with 3+ choices), you really want to represent a structure like so:
{'highlight_mode': {7: 'blue', 9: 'yellow'}}
Where the values to the corresponding id keys are part of a known enumeration. What's the best way to encode this into a query string? I'm thinking of using a sequence of two-tuples like so:
?highlight_mode=(7,blue)&highlight_mode=(9,yellow)
Edit: It would also be nice to know any names that associate with the conventions. I know that there may not be any, but it's nice to be able to talk about something specific using a name instead of examples. Thanks!
The usual way is to do it like this:
highlight_mode[7]=blue&highlight_mode[9]=yellow
AFAIR, quite a few server-side languages actually support this out of the box and will produce a nice dictionary for these values.
I've also seen people JSON-encode the nested dictionary, then further encode it with BASE64 (or something similar), then pass the whole resulting mess as a single query string parameter.
Pretty ugly.
On the other hand, if you can get away with using POST, JSON is a really good way to pass this kind of information back and forth.
In many Web frameworks it's encoded differently from what you say.
{'foo': [1], 'bar': [2, 3], 'fred': 4}
would be:
?foo[]=1&bar[]=2&bar[]=3&fred=4
The reason array answers should be different from plain answers is so the decoding layer can automatically tell the less common foo case (array which just happens to have a single element) from extremely common fred case (single element).
This notation can be extrapolated to:
?highlight_mode[7]=blue&highlight_mode[9]=yellow
when you have a hash, not just an array.
I think this is pretty much what Rails and most frameworks which copy from Rails do.
Empty arrays, empty hashes, and lack of scalar value look identical in this encoding, but there's not much you can do about it.
This [] seems to be causing just a few flamewars. Some view it as unnecessary, because the browser, transport layer, and query string encoder don't care. The only thing that cares is automatic query string decoder. I support the Rails way of using []. The alternative would be having separate methods for extracting a scalar and extracting an array from querystring, as there's no automatic way to tell when program wants [1] when it wants 4.
This piece of code works for me with Python Backend-
import json, base64
param={
"key1":"val1",
"key2":[
{"lk1":"https://www.foore.in", "lk2":"https://www.foore.in/?q=1"},
{"lk1":"https://www.foore.in", "lk2":"https://www.foore.in/?q=1"}
]
}
encoded_param=base64.urlsafe_b64encode(json.dumps(param).encode())
encoded_param_ready=str(encoded_param)[2:-1]
#eyJrZXkxIjogInZhbDEiLCAia2V5MiI6IFt7ImxrMSI6ICJodHRwczovL3d3dy5mb29yZS5pbiIsICJsazIiOiAiaHR0cHM6Ly93d3cuZm9vcmUuaW4vP3E9MSJ9LCB7ImxrMSI6ICJodHRwczovL3d3dy5mb29yZS5pbiIsICJsazIiOiAiaHR0cHM6Ly93d3cuZm9vcmUuaW4vP3E9MSJ9XX0=
#In JS
var decoded_params = atob(decodeURI(encoded_param_ready));