On 05/09/14 21:51, "Thiago Macieira" <[email protected]> wrote:
>On Friday 05 September 2014 09:16:48 André Somers wrote: >> > This did not extract the string for translation. It needs to be >>something >> > that does extract for translation and does translate to another >>language >> > if a translator was loaded. >> >> I don't see how it properly could. Both strings would be specialized >> anyway for the singular and plural case. The singular version probably >> would not even have a placemarker for the number in it. How would that >> work in the translation? You could still use a translatable string for >> both alternatives, but I think that's completely missing the point. You >> either do localization, or you don't. This really sounds like a weird >> in-between, non-solution to me. > >Fortunately for us, existing implementations have done this successfully >for >years and prove it's possible. > >https://techbase.kde.org/Development/Tutorials/Localization/i18n#Plurals Yes, this works for KDE that has a policy that all source strings are in english. While we have the same policy for Qt itself, I don’t think we can require the same thing from our users. And then a two form API simply feels wrong. Now I would consider it a good thing if we had a better way of automatically loading all relevant translation files for an application. IMO this also requires a policy of how they get packaged during deployment. Cheers, Lars _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
