-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with OGs and FGs for each style (2.3.0) #166
Comments
I noticed the same issue in the Volume of the Mash Tun 378.541.178,000 L |
In Spanish we write the numbers in that format: ',' is a decimal separator and '.' is a thousand separator. |
Is this still an issue? I will take yet another swing at the internationalization stuff if I need to. |
Unfortunately, is still an issue here. I have updated to the Version 2.3.1.1 and still have the same problem |
OK. I will see if i can fix it. Thanks.
|
What is your locale set to? This looks like brewtarget thinks you are in a Mik Hi, I'm using Ubuntu 14.04 LTS, Qt 5.2.1, and here is the output — |
I'm in Brazil, and here we use the "." as thousand separator, and "," as decimal point. But on the older version of BT 2.1.0, this problem doesn't appear. I didn't change anything after the upgrade to 2.3.1. Sorry, if its something obvious but I thought that it wouldn't change from one to another. Where can I change the locale? |
@rocketman768 Sorry, I just saw the mention today. I wasn't using Brewtarget for a while but I compiled it today (from "develop" branch). I think there is something odd indeed, but it's not everywhere. My mash tun volume is fine (32 L), and for example the American Amber Ale has the right statistics (OG 1,045 - 1,060; FG 1,010 - 1015), but some other styles have wrong data: It is really mixed as described. I'll take a further look tomorrow, but overall the recipe's values look good. @JAUCBN You can test setting BTW, the issue doesn't happen using |
@renato I tried opening with Thanks for the help, also to @rocketman768 and @mikfire , and sorry to bother. |
Thank you very much for reporting the bug. I will fix it, and I am glad you Mik
|
The fun part about this is that brewtarget doesn't do any anything with respect to internationalization. Anything to do with displaying the numbers properly for the specific locale is left to Qt. I will investigate more, but I am not really sure this is our problem. It may be something weird in Qt. |
Hello. See yelow in image, OG for this style don't have min and max range. In FG have min range, but don't have max range. Have S.I. units, and 20/20 C S.G. configured in options. |
Out of curiosity, what is your LANG environmental variable set to? Mik Mik Firestone On Sat, Nov 12, 2016, at 21:22, castreixanas wrote:
Links: |
hello, my system complete report you can view in this url: http://speccy.piriform.com/results/5DX4gOTQLInkBE7FV84uewZ lang is spanish es-es, spain international alphabet. If you want, I can test in my system your arrangements. 2016-11-13 4:39 GMT+01:00 mikfire [email protected]:
|
Hi.
I discovered the problem.
When windows in the regional configuration is configured in "spanish united
states (es_us)", brewtarget works fine.
When configured "Spanish Spain (es_es)", brewtarget does not work well.
The point is that in the USA the thousands separator is "," and the decimal
separator is "."
While in Spain (and throughout Europe, except UK) the thousands separator
is "." And the decimal separator is ","
So brewtarget gets into a mess by transforming the data, and most fields
parse it wrong.
Correct format in Metric Countries is xxx.xxx.xxx,xx or xxx xxx xxx,xx
and in Imperial Countries xxx,xxx,xxx.xx
In brewtarget options you can choose the regional system for weight and volume (these are shown correctly), but you can not choose for srm ebc, sg, etc. So it is possible that only the latter are those that are incorrectly parsed.
Please be grateful if it is possible to launch an urgent patch for this
problem, as it becomes quite difficult to use the program under these
conditions. (And probably this problem is currently replicating in all
users of the metric system, which is the majority of countries in the
world).
Thank you.
2016-11-13 4:39 GMT+01:00 mikfire <[email protected]>:
… Out of curiosity, what is your LANG environmental variable set to?
Mik
--
Mik Firestone
***@***.***
On Sat, Nov 12, 2016, at 21:22, castreixanas wrote:
> Hello.
> Have a bug with OG and FG ranges.
> See yelow in image, OG for this style don't have min and max range. In
> FG have min range, but don't have max range.
> In style editor OG min range mask is x.xxx,xxx sg and max range x,xxx
> sg. FG is min x,xxx sg and max range x.xxx,xxx sg.
> I change to x,xxx format, but I can't save.
> Have S.I. units, and 20/20 C S.G. configured.
> captura
> — You are receiving this because you were mentioned. Reply to this
> email directly, view it on GitHub[1], or mute the thread[2].
>
Links:
1. #166#
issuecomment-260162215
2. https://github.com/notifications/unsubscribe-auth/AKxgF-sH-QI5X1J-
wbWLwwy6OpzxpVvSks5q9nRmgaJpZM4HSxpB
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#166 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AWV2rnK1LQBn4PjKD-9WbZ8eEB0TjVnbks5q9oaHgaJpZM4HSxpB>
.
|
@mikfire, do we know if this is still an issue? EDIT: I could not replicate by switching my Ubuntu to es_es. I specifically like how when you change de language it apparently asks you whether you want to change all of your home folder names to the new language... I am glad I could Google Translate that prompt. |
It is. I think I have half a clue as to what is happening. It isn't
still the full story, because I cannot explain why it happens only in
some fields, not all.
This is what is happening.
1. The default database is built using en_US.utf8 encoding;
2. This causes things like the OG min/max to be written using numbers
like 1.010 or 1.045 -- en_US decimal separator, so this would be
1,010 or 1,045 in pt_BR;
3. We read these numbers from the database. The nature of this call
translates the double into a QVariant and then into a QString that
looks like "1.010" or "1.045";
4. We call Brewtarget::toDouble(), which gets the system Locale and
calls QLocale::toDouble(). Well, in a pt_BR locale, "1.045" gets
converted into 10^3 + 45 or (as we would write it in en_US 1,045).
I guess we should be treating the encoding like we do SI -- everything
gets stored in a known encoding and then we leave it until the very,
very end to display in the current locale.
The really hard part is how to fix what is already broken. For that, I
would need to look at a broken database and see what values are being
stored and come up with a plan for fixing.
Mik
--
Mik Firestone
[email protected]
On Tue, Jan 10, 2017, at 14:05, Maxime Lavigne (malavv) wrote:
@mikfire[1], do we know if this is still an issue?
— You are receiving this because you were mentioned. Reply to this
email directly, view it on GitHub[2], or mute the thread[3].
|
Actually, I think I have an astonishingly easy fix. It's a little brute force. The reason it only happened in some fields was that I was using slightly different methods. Most places invoked BtLineEdit::setText(double amount, int precision). StyleEditor was using a small bit of syntax sugar I created and called BtLineEdit::setText(BeerXMLElement *element). As long as I force things to use the first call instead of the second, the gravities are displayed correctly as it will never go through the conversions. I still need to think about this and make some tests to verify the solution is this relatively straight forward. I will also likely need to break my database a bit. I may get a solution checked in tonight. |
I really would like to believe pull request #336 fixes this. If somebody in the afflicted region could test the branch and see if it works, I would be grateful. |
Hi. I can do the test. But I need a compiled version for windows, and I do not know where to download it. Or teach me another way I can do the test. I am waiting for the information or the download link. Greetings. |
I installed the Linux 64-bit version of the 2.3.0, and I'm facing some problems with the OGs and FGs for each style. They are appearing with dots and commas mixed, and higher values.
For example: Belgian Golden Strong Ale
OG min: 1,070 sg
OG max: 1.095,000 sg
FG min: 1.050,000 sg
FG max: 1.016,000 sg
Do you know what's wrong?
Thanks
The text was updated successfully, but these errors were encountered: