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
Replace tinyfmt with fmt (https://github.com/fmtlib/fmt) #773
Comments
Is this being worked on? |
I've got the initial port working locally, but haven't had time to polish it and properly test (e.g. all the translation strings need to be updated, so I was using this as a good point to make the strings extracted automatically from code with xgettext as a build target etc) It also revealed a number of "bad" translation policies - e.g. stitching together translated text fragments instead of doing the wrong string at a time (e.g. something like "format(tr("%s, %s"), format(tr("%s thing is %d out of "), object, count), format(tr(out of "%d total"), number)); Which would result in the completely useless strings for translators: when it really should be translated as a single call, so the extracted string should be: |
From what I can gather there has to be two distinct formatting subsystems:
I would propose implementing them in small steps: first switch to |
I am unsure if boost::locale is actually going to be that useful for us going forward - it's great for static applications with static translation databases, but I have struggled to find where I can hook into it's message database to add in new messages from mods. I think it's only possible to add a completely new database in a new translation domain, and then we get into issues trying to figure out which domain we should translate a string with, without doing something like trying /all/ mod domains in order until we find a match |
So my current plan is to try to separate each of the tasks - similar to what you mentioned:
I have pretty much all the above stages locally in various states - it probably makes sense for me to try get them into a usable state, and now I have a bit of time this long weekend I guess that'll be my next task :) |
Once that is all done, we can then start to worry about how mods would work that add new strings |
Actually they only look similar --
Though I find support for plural forms much more valuable. |
Yeah, I remember the indexing throwing me to begin with :) TBH going forward I think the boost::locale format is good to go, I'm sure we can fix the mod context issues going foward. Or at least then when we find the "next" problem all the translated strings will be in a much more sane format and not intermingled with non-translated formatted text. |
Also, honestly the entire UString class should be a set of helpers around a std::basic_string<char8_t> - but that looks like it won't be reliably around until c++20. I'm temped to just replace it all with a std::string (IE std::basic_string), but then we'll lose type safety for "known utf8" vs "array of bytes" - but I'm not sure we're really using that anyway. We'd just have to be careful at interfaces, but we aren't careful today, just calling .cStr()/.str() without any real conversion as a 'get out' IT currently 'happens' to work as I tend to test on platforms that use utf8 in their system APIs already - but I suspect it'll currently break if we try to do something today like open a filename with a non-ascii path on windows |
fmt:
compared to tinyformat.
The text was updated successfully, but these errors were encountered: