Thanks for reporting this, I have tried to investigate, I managed to reproduce, but the parser is a bit of a blackbox for me, so it's not a trivial fix.

@PioneerAxon: could you help me out a bit with this? I've tried to debug the issue, it reproduces, but can't find the issue in the equation parser, where it fails. Also, if you have the time a short summary on how to find/debug these kind of parsing issues would be really welcome for me to be able to find and fix the next similar issue without begging for your help :)

This is very annoying and a bit a blocker for 3.26 in IMHO

(In reply to Laurent Bigonville from comment #2)
> This is very annoying and a bit a blocker for 3.26 in IMHO

After some investigation I have finally found the reason. The result of the previous operation is always stored in a variable called "ans", which in french locale is also a shorthand for the "years" unit. So the solution would be to either rename the "ans" variable or to remove the "ans" shorthand from the french locale.

Both options have their ups and downs: 
* renaming the variable might disrupt people who use the "ans" variable (which might be simply no one), but choosing a variable with a strange name ("last_answer") will reduce the possibility of this happening again with another translation
* removing the "ans" shorthand will result in French people only being able to use "an,année,années" to shorthand unit conversions like "10 years in days", but has the advantage of being a translation-only change, which can safely be done this late in the cycle.

Based on the above, I am going forward with the second option, to have a quick and safe fix to resolve a blocker, and will think for a proper solution (which might be controversial if there is anyone using the "ans" variable) for the next cycle.

Thanks for reporting this.

This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.

(In reply to Robert Roth from comment #3)
> * removing the "ans" shorthand will result in French people only being able
> to use "an,année,années" to shorthand unit conversions like "10 years in
> days", but has the advantage of being a translation-only change, which can
> safely be done this late in the cycle.
> 
> Based on the above, I am going forward with the second option, to have a
> quick and safe fix to resolve a blocker, and will think for a proper
> solution (which might be controversial if there is anyone using the "ans"
> variable) for the next cycle.

As an i18n coordinator, I disapprove of a maintainer changing translations themselves. At the very least you should have brought it up to the French team.

As the French coordinator, I’d like to point out that:
* ans is the plural of an and if someone were to convert 10 years in days as in your example, they’ll most probably type ans and expect it to work
* 10 ans is also way more idiomatic than années

I find it highly ironic that your fix for something that's been reported as not working with the French translation is to break something else with the French translation.

Adding to what Alexandre said, since I haven't seen it mentioned...

> a variable called "ans", which in french locale is also a shorthand for the "years" unit.

This is not a shorthand in French. It is a full word, and effectively a (quasi-)synonym to "années".

(In reply to Alexandre Franke from comment #5)

> As an i18n coordinator, I disapprove of a maintainer changing translations
> themselves. At the very least you should have brought it up to the French
> team.
> 
> As the French coordinator, I’d like to point out that:
> * ans is the plural of an and if someone were to convert 10 years in days as
> in your example, they’ll most probably type ans and expect it to work
> * 10 ans is also way more idiomatic than années
> 
> I find it highly ironic that your fix for something that's been reported as
> not working with the French translation is to break something else with the
> French translation.


Ok, sorry for that. As discussed, the other option for fixing was renaming the variable, which requires code freeze exception. I will in any case reopen and revert, and see if that can be done in a timely manner to not block the release.
I wasn't aware of the implications, that is my mistake. Sorry once again for that.

(In reply to Robert Roth from comment #3)
> Both options have their ups and downs: 
> * renaming the variable might disrupt people who use the "ans" variable
> (which might be simply no one), but choosing a variable with a strange name
> ("last_answer") will reduce the possibility of this happening again with
> another translation

Unfortunately the variable name is used in the help, so for the fix to be complete the variable name change should be reflected in all help files (translations of variables.page), and is rejected due to the fact that maintainers should not change translations themselves.

> * removing the "ans" shorthand will result in French people only being able
> to use "an,année,années" to shorthand unit conversions like "10 years in
> days", but has the advantage of being a translation-only change, which can
> safely be done this late in the cycle.
> 
This solution excluded due to French i18n team coordinator (rightful) disapproval.

I have been experimenting with other solutions, e.g. updating the parser to check if a given string is a variable, and if a variable exists then treat it as a variable, but that will also break the unit conversion in french, and instead of "ans" variable not being usable, unit conversion will be broken, so "1 ans in jours" will not work.

Maybe it would be possible to extend the parser to be able to work with cases like this, but I could not do it, as doing that is quite a big task, not quickly doable and error-prone, and needs testing. 

So right now given the fact that French people consider this bug a blocker for 3.26.0 and I have no solutions left to try, I am thinking of not releasing 3.26.0 stable (due today).

Ideas, suggestions are welcome. I am stuck here.

Hi Robert,

Why don't you translate the variable 'ans', by 'res' or 'mem' in french, and leave it untranslated for all other localess. That way, only the french locale is impacted by the changes.

In other systems, the last result is stored in a variable named `_` (e.g the Python shell) or `$_` (e.g the Firefox web developer console).

Those won't conflict with any locale-specific strings, since they aren't words.

Of course, it does mean that it's not something you can do for 3.26.0. :(

(In reply to Emmanuel Pacaud from comment #9)
> Hi Robert,
> 
> Why don't you translate the variable 'ans', by 'res' or 'mem' in french, and
> leave it untranslated for all other localess. That way, only the french
> locale is impacted by the changes.

The idea of having translation for only one specific locale as a workaround for a problem does not really sound tempting.

(In reply to Mathieu Bridon from comment #10)
> In other systems, the last result is stored in a variable named `_` (e.g the
> Python shell) or `$_` (e.g the Firefox web developer console).
> 
> Those won't conflict with any locale-specific strings, since they aren't
> words.
> 
> Of course, it does mean that it's not something you can do for 3.26.0. :(

I don't really like the idea of having non-text variable. But still, this seems the best option so far. As adding support for $_ would mean extending the parser, I'm thinking about moving to '_' as a variable name for the last result. And I will request a freeze exception, even though 3.26.0 was already released, maybe it can get in 3.26.1. (with all help file translations updated to refer to '_' instead of 'ans' ). Thanks for the suggestion.

Created attachment 359903 [details] [review]
Use _ instead of ans for last result (bgo#785107)

This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.

Commit is ad694dba6d13633bb5a2ec6f41b3a3fe9758007d

*** Bug 792723 has been marked as a duplicate of this bug. ***

Could somebody enlighten me as to why/how "ans" would have been translated?

There's two "_" strings to translate from what I could see, and both of them have contexts associated. If this doesn't change the translations, it would really be useful to have this fix in a stable bug-fix release.

*** Bug 792893 has been marked as a duplicate of this bug. ***