search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.16k stars 5.41k forks source link

Giteabot makes unnecessary escape for Korean translation #31606

Open cloudchamb3r opened 2 months ago

cloudchamb3r commented 2 months ago

Description

Please refer to https://github.com/go-gitea/gitea/commit/de265f377113766124e9846e120e2864bf01c60c

Gitea CI Bot Does Unnecessary Escapes for Korean Translation

Screenshots

Screenshot 2024-07-10 at 1 53 54 PM

Gitea Version

1.20~

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

OSX

Browser Version

chrome 126.0.6478.127

lunny commented 2 months ago

It's the translation problem, please help to correct it in https://translate.Gitea.com

yp05327 commented 1 month ago

image https://crowdin.com/editor/gitea/68/enus-ko?view=comfortable&filter=basic&value=0#q=issues.opened_by

image

@lunny It is a bit strange. It seems that it is correct in Crowdin.

yp05327 commented 3 weeks ago

There are also some other strange changes. All come from https://github.com/go-gitea/gitea/commit/de265f377113766124e9846e120e2864bf01c60c

wxiaoguang commented 3 weeks ago

There are also some other strange changes. All come from de265f3

See my comments for more information

image

image

yp05327 commented 3 weeks ago

I see where these double quotes come from and how it works. So after the original locale files pulled from Crowdin, we will finally do some modified by the script before push. (according to the workflow file)

Then I executed the script in my local, then I got this: image So if I understand correctly, if everything is correct, this should not happen, right?

wxiaoguang commented 3 weeks ago

So if I understand correctly, if everything is correct, this should not happen, right?

"If everything is correct, this should not happen, right?": yes, the quotes should have been "cleaned up".

(I didn't look into it so I have no idea, just share some backgrounds)

yp05327 commented 3 weeks ago

I think I know what happened. I notice the comment in L3:

this script runs in alpine image which only has sh shell

Then I find the original PR is #23254. According to it, we were use Drone before, so this script is designed for Apline before. Then I checked the OS where I executed the script, it is dev container which is Debain. And we are using Github Actions, it uses Ubuntu. Then I run the script in WSL which is Ubuntu, NOTHING happened.

So this script should be changed, or it should not run in Ubuntu, which will cause this issue.

yp05327 commented 3 weeks ago

The version of sed:

In WSL:

sed (GNU sed) 4.8 Packaged by Debian Copyright (C) 2020 Free Software Foundation, Inc.

In Dev Container: bullseye

sed (GNU sed) 4.7 Packaged by Debian Copyright (C) 2018 Free Software Foundation, Inc.

bookworm

sed (GNU sed) 4.9 Packaged by Debian Copyright (C) 2022 Free Software Foundation, Inc.

wxiaoguang commented 3 weeks ago

And we are using Github Actions, it uses Ubuntu. Then I run the script in WSL which is Ubuntu, NOTHING happened.

Ubuntu's "sh" defaults to "dash", which has many differences

lunny commented 3 weeks ago

Maybe we should rewrite these logic with Go code to avoid inconsistent between shell script commands.

denyskon commented 3 weeks ago

The only reason we need this script is the ini format we're using for translations. As I think that we want to switch to another format anyway (#27700), it wouldn't make sense to build a new tool for it.

lunny commented 2 weeks ago

The only reason we need this script is the ini format we're using for translations. As I think that we want to switch to another format anyway (#27700), it wouldn't make sense to build a new tool for it.

Ah, yes. But we need to fix the bug before a new format comes out.