On Mon, May 08, 2017 at 09:49:34AM -0700, Stefan Beller wrote: > On Sat, May 6, 2017 at 1:40 AM, Jordi Mas <jmas@xxxxxxxxxxxxxx> wrote: > > Hello, > > > > When translating git (https://github.com/git/git/tree/master/po) > > > > The following strings cannot be translated: > > > > remote: Counting objects: 331, done. > > remote: Compressing objects: 100% (213/213), done. > > remote: Total 244 (delta 184), reused 34 (delta 29) > > This is what the remote server tells a client, but the client did not > tell the server which locale it has. > > Now consider we have hosting service that hosts projects accessible from > a wide range of users, all of them having different locales. Which language > should the remote speak? (Not knowing which language the client speaks). In theory the client could pass the locale variables. We probably already do by default over ssh. Likewise we could ask curl to send an HTTP header based on the current locale, and the server could respect that. That probably wouldn't even be that much code. I think it's just something that nobody has bothered to implement so far. > > 27 files changed, 3399 insertions(+), 3320 deletions(-) > > create mode 100644 build-aux/flatpak/org.gnome.Nautilus-stable.json > > delete mode 100755 build-aux/meson/check_libgd.sh > > These sound like they are done locally and could be translated easily. > However I wonder if we have issues with leaky plumbing in the user porcelain. I don't think the diffstat summary is marked for translation at all, plumbing or not. There's some history there: http://public-inbox.org/git/1345922816-20616-1-git-send-email-pclouds@xxxxxxxxx/t/#u There was an attempt to re-enable it for local-only commands: http://public-inbox.org/git/alpine.DEB.2.00.1210231323480.602@xxxxxxxxxxxx/ but nobody seems to have responded (I don't have much of an opinion myself). -Peff