Qt internationalization system with different positioned strings - qt

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...

Related

getopt_long confusion, flag setting with single-char switches

I'm parsing command line options using getopt_long based on the example from the man page. That example does something a bit sneaky, it includes two flag-setting options in long_options but does not list those in the short form parameter string in getopt_long.
Poking about, this answer clarifies what happens in this case, if they enter the short-form it does not set the flag. And leads to my question: If you have a flag-setting switch, and you want to have both long and short forms for that switch on the command line...
Did I miss an option in the short-form string to set flags, sort of like how : works for indicating a parameter follows? Like "v?1" or something?
Failing that, is it best-practices to not do it in the long-form as well, and just return 'v'? Or would "the average code" use the flag-set and have separate code in the switch?
I'd like my code to be "as standard as possible", whatever that means, which is my I'm curious about (2).

Dynamic Receiver in Powermail (6.0.0) based on String

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

What's the correct format for TCDL linkAttributes?

I can see the technology-independent Tridion Content Delivery Language (TCDL) link has the following parameters, which are pretty well described on SDL Live Content.
type
origin
destination
templateURI
linkAttributes
textOnFail
addAnchor
VariantId
How do we add multiple attribute-value pairs for the linkAttributes? Specifically, what do we use to escape the double quotes as well as separate pairs (e.g. if we need class="someclass" and onclick="someevent").
The separate pairs are just space delimited, like a normal series of attributes. Try XML encoding the value of linkAttributes however. So, " become &quote;, etc...
If you are using some Javascript, you might take care of the Javascript quotes too, as in \".
Edit: after I figured out your real question, the answer is a lot simpler:
You should wrap the values inside your linkAttributes in single quotes. Spaces inside linkAttributes are typically handled fine; but if not, escape then with %20.
If you need something more or want something that isn't handled by the standard tcdl:ComponentLink, remember that you can always create your own TCDL tag and and use a TagHandler or TagRenderer (look them up in the docs for examples or search for Jaime's article on TagRenderer) to do precisely what you want.
My original answer was to a question you didn't ask: what is the format for TCDL tags (in general). But the explanation might still be useful to some, so remains below.
I'd suggest having a look at what format the default building blocks (e.g. the Link Resolver TBB in the Default Finish Actions) output and use that as a guide line.
This is what I could quickly get from the transport package of a published page:
<tcdl:Link type="Page" origin="tcm:5-199-64" destination="tcm:5-206-64"
templateURI="tcm:0-0-0" linkAttributes="" textOnFail="true"
addAnchor="" variantId="">Home</tcdl:Link>
<tcdl:ComponentPresentation type="Embedded" componentURI="tcm:5-69"
templateURI="tcm:5-133-32">
<span>
...
One of the things that I know from experience: your entire TCDL tag will have to be on a single line (I wrapped the lines above for readability only). Or at least that is the case if it is used to invoke a REL TagRenderer. Clearly the tcdl:ComponentPresentation tag above will span multiple lines, so that "single line rule" doesn't apply everywhere.
And that is probably the best advice: given the fact that TCDL tags are processed at multiple points in Tridion Publishing, Deployment and Delivery pipeline, I'd stick to the format that the default TBBs output. And from my sample that seems to be: put everything on a single line and wrap the values in (double) quotes.

Base search/find functionality (Ctrl+F) in AX 2009/2012 doesn't work properly...how to fix?

I feel like I might be losing my mind...but if you search the AOT for anything with double colons "::", it fails completely. I'm trying to step through the Forms\SysAotFind to figure this out but I didn't want to spin my wheels a bunch for something that might be on my system only.
To reproduce in AX 2009, select Classes\SalesTableType, press Ctrl+F and put "CustLedgerAccounts::sumAccount" in the containing text box and click find now. You can see this is clearly located in the Classes\SalesTableType\accountCust method. I've tried searching for base enums inside objects with no luck either.
I noticed the same behavior, but escaping the colons with a backslash makes the search work correctly.
So in your case you would need to search for "CustLedgerAccounts\:\:sumAccount".
The search uses regular expressions in the syntax defined by the match function.
Colon is a special character, hence it needs to be escaped by a backslash.
For those searching for a fix, you can see where the issue is here and just tweak it if you want to allow specifically for double colons:
[c] \Classes\SysTreeNodeSearch\isNodeInRange #46
if (!match(containingText,source))
return false;

ASP.NET Localization with singular and plural

Can I with ASP.NET Resources/Localization translate strings to depend on one or other (the English grammar) in a easy way, like I pass number 1 in my translate, it return "You have one car" or with 0, 2 and higher, "You have %n cars"?
Or I'm forced to have logic in my view to see if it's singular or plural?
JasonTrue wrote:
To the best of my knowledge, there isn't a language that requires something more complicated than singular/plural
Such languages do exist. In my native Polish, for example, there are three forms: for 1, for 2-4 and for zero and numbers greater than 4. Then after you reach 20, the forms for 21, 22-24 and 25+ are again different (same grammatical forms as for numerals 0-9). And yes, "you have 0 things" sounds awkward, because you're not likely to see that used in real life.
As a localization specialist, here's what I would recommend:
If possible, use forms which put the numeral at the end:
a: Number of cars: %d
This means the form of the noun "car" does not depend on the numeral, and 0 is as natural as any other number.
If the above is not acceptable, at least always make a complete sentence a translatable resource. That is, do use
b: You have 1 car.
c: You have %d cars.
But never split such units into smaller fragments such as
d: You have
e: car(s)
(Then somewhere else you have a non-localizable resource such as %s %d %s)
The difference is that while I cannot translate (c) directly, since the form of the noun will change, I can see the problem and I can change the sentence to form (a) in translation.
On the other hand, when I am faced with (d) and (e) fragments, there is no way to make sure the resulting sentence will be grammatical. Again: using fragments guarantees that in some languages the translation will be anything from grammatically awkward to completely broken.
This applies across the board, not just to numerals. For example, a fragment such as %s was deleted is also untranslatable, since the form of the verb will depend on the gender of the noun, which is unavailable here. The best I can do for Polish is the equivalent of Deleted: %s, but I can only do it as long as the %s placeholder is included in the translatable resource. If all I have is "was deleted" with no clue to the referent noun, I can only startle my dog by cursing aloud and in the end I still have to produce garbage grammar.
I've been working on a library to assist with internationalization of an application. It's called SmartFormat and is open-source on GitHub.
It contains "grammatical number" rules for many languages that determine the correct singular/plural form based on the locale. When translating a phrase that has words that depend on a quantity, you specify the multiple forms and the formatter chooses the correct form based on these rules.
For example:
var message = "There {0:is:are} {0} {0:item:items} remaining.";
var output = Smart.Format(culture, message, items.Count);
It has a very similar syntax to String.Format(...), but has tons of great features that make it easy to create natural and grammatically-correct messages.
It also deals with possible gender-specific formatting, lists, and much more.
moodforaday wrote:
This applies across the board, not just to numerals. For example, a fragment such as "%s was deleted" is also untranslatable, since the form of the verb will depend on the gender of the noun, which is unavailable here. The best I can do for Polish is the equivalent of "Deleted: %s", but I can only do it as long as the %s placeholder is included in the translatable resource. If all I have is "was deleted" with no clue to the referent noun, I can only startle my dog by cursing aloud and in the end I still have to produce garbage grammar.
The point I would like to make here, is never include a noun as a parameter. Many European languages modify the noun based on its gender, and in the case of German, whether it is the subject, object, or indirect object. Just use separate messages.
Instead of, "%s was deleted.", use a separate translation string for each type:
"The transaction was deleted."
"The user was deleted." etc.
This way, each string can be translated properly.
The solution to handle plural forms in different languages can be found here:
http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
While you can't use the above software in a commercial application (it's covered under GPL), you can use the same concepts. Their plural form expressions fit perfectly with lambda expressions in .NET. There are a limited number of plural form expressions that cover a large number of languages. You can map a particular language to a lambda expression that calculates which plural form to use based on the language. Then, look up the appropriate plural form in a .NET resx file.
There is nothing built in, we ended up coding something like this:
Another solution can be:
use place holders like {CAR} in the resource file strings
Maintain separate resource entries for singular and plural words for "car" :
CAR_SINGULAR car
CAR_PLURAL cars
Develop a class with this logic:
class MyResource
{
private List<string> literals = new List<string>();
public MyResource() { literals.Add("{CAR}") }
public static string GetLocalizedString(string key,bool isPlural)
{
string val = rm.GetString(key);
if(isPlural)
{
val = ReplaceLiteralWithPlural(val);
}
else
{
val = ReplaceLiteralWithSingular(val);
}
}
}
string ReplaceLiteralWithPlural(string val)
{
StringBuilder text = new StringBuilder(val)
foreach(string literal in literals)
{
text = text.Replace(literal,GetPluralKey(literal));
}
}
string GetPluralKey(string literal)
{
return literal + "_PLURAL";
}
This is still not possible in .NET natively. But it is a well known problem and already solved by gettext. It have native support for many technologies, even includes C# support. But looks like there is modern reimplementation now in .NET: https://github.com/VitaliiTsilnyk/NGettext
Orchard CMS uses GNU Gettext's PO files for localization and plural forms.
Here is their code where you can grab the idea:
https://github.com/OrchardCMS/OrchardCore/tree/main/src/OrchardCore/OrchardCore.Localization.Core
https://github.com/OrchardCMS/OrchardCore/tree/main/src/OrchardCore/OrchardCore.Localization.Abstractions
The logic needn't be in your view, but it's certainly not in the resource model the DotNet framework. Yours is a simple enough case that you can probably get away with creating a simple format string for singular, and one for plural. "You have 1 car."/"You have {0} cars." You then need to write a method that discriminates between the plural and singular case.
There are also a number of languages where there's no distinction between singular and plural, but this just requires a little duplication in the resource strings. (edit to add: gender and sometimes endings change depending on number of units in many languages, but this should be fine as long as you distinguish between singular and plural sentences, rather than just words).
Microsoft mostly gave up on semantically clever localization because it's hard to generalize even something like pluralization to 30+ languages. This is why you see such boring presentation of numeric quantities in most applications that are translated to many languages, along the lines of "Cars: {0}". That sounds lame, but surprisingly, the last time I checked, usability studies didn't actually favor the verbose natural language presentation in most cases.

Resources