Skip to content
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

Translation process #114

Closed
lunny opened this issue Nov 8, 2016 · 33 comments
Closed

Translation process #114

lunny opened this issue Nov 8, 2016 · 33 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Milestone

Comments

@lunny
Copy link
Member

lunny commented Nov 8, 2016

I have ever gave this idea on Gogs. Now I give it again.

I think we can develop a language editor UI on admin panel. It could simple, there are two columns, left is English, right is another, he can select one from the supported languages above right column.
Every line is a translate, left is english word, right is the special language. After finished the translation, he can save it. After that, he can go and look at the UI immediately. Of course, if he like, he can download the locale file and send a PR to gitea repo.

@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Nov 8, 2016
@lunny lunny added this to the 1.1.0 milestone Nov 8, 2016
@strk
Copy link
Member

strk commented Nov 8, 2016

Sounds like reinventing the wheel to me. This is what specialized translation code does.

@metalmatze
Copy link
Contributor

I really like the idea if the tool is kept simple, yet I still don't know if that should be port of gitea.

@joubertredrat
Copy link
Contributor

@lunny this Idea is good, but Gitea will lose standard among all installations, since the user will be able to customize your translations. With this, I think that will be more hard to we understand and solve possible issues about UI.

@lunny
Copy link
Member Author

lunny commented Nov 8, 2016

So we have to assign language tanslation maintainer for LGTM locale file PRs.

@joubertredrat
Copy link
Contributor

joubertredrat commented Nov 8, 2016

@lunny Then I think that's the way it's better.

Option to change translations, a big alert stating that the layout may break if you do not use the feature with care and a resource displaying when local translation isn't default from Gitea.

Whit this I think we can avoid possible issues as this

"Problem with right menu #114"
"
Guys, my menu is bigger and ugly, I'm opening this issue to solve this
screenshot-repo

"

@joubertredrat
Copy link
Contributor

joubertredrat commented Nov 8, 2016

@lunny ah, other problem, will be more easy to use translation on admin to XSS, because current translations have some html elements. A not a nice person can put similar to <script>getMy(document.cookie)</script> as example. On specialized tools is more easy to translate and manager translations to avoid this problems.

@lunny
Copy link
Member Author

lunny commented Nov 8, 2016

Hi, I think that's great! Users should control the size of name themselves.

@joubertredrat
Copy link
Contributor

When ins't defined this question, isn't good idea at least change manually on files from Gogs to Gitea for first release?

@bkcsoft
Copy link
Member

bkcsoft commented Dec 2, 2016

My take on this is more related to backend than frontend.

Keep all translation-files in a separate repo (subtree for pulling into Gitea).
Pros:

  • Each new translation-update can be done as a separate branch, without having to rebase on gitea-updates every 5 minutes.
  • Each branch can be spun up as a separate container on gitea.io for easy testing (e.g. new_branch.translate.gitea.io)
  • If new translations are added in en_US on master, you can easily rebase without having to update Gitea (less error prone at least)
  • Translation-tools that speak git (e.g. Weblate ) can be used without fscking around with the gitea history

Cons:

  • Someone has to merge the translations back into Gitea when they are mainlined :trollface:

Feel free to pitch in on pros/cons for this, as this list is very biased and I can't really find any cons 😕

@tboerger
Copy link
Member

tboerger commented Dec 2, 2016

Maybe we should also use a more mature format like gettext? :)

@joubertredrat
Copy link
Contributor

joubertredrat commented Dec 26, 2016

@tboerger we need a colaborative platform to be easy to any Gitea collaborator help and we manage, like Weblate, Pootle and Zanata or Crowdin.

@lunny
Copy link
Member Author

lunny commented Dec 27, 2016

I remember @tboerger has sent a request to Weblate?

@lunny
Copy link
Member Author

lunny commented Jan 6, 2017

https://weblate.org/en/hosting/ @tboerger has you apply on this?

@strk
Copy link
Member

strk commented Jan 6, 2017 via email

@Bwko
Copy link
Member

Bwko commented Jan 8, 2017

We could host weblate on our own server

@joubertredrat
Copy link
Contributor

joubertredrat commented Jan 8, 2017 via email

@lunny
Copy link
Member Author

lunny commented Jan 8, 2017

If we cannot received the response some days, we could consider host it on our server.

@joubertredrat
Copy link
Contributor

This sound suggestive 👍

https://github.com/anthonynsimon/parrot

@metalmatze
Copy link
Contributor

It was already discussed and proposed, so yes. Considering it.

@lunny
Copy link
Member Author

lunny commented Feb 5, 2017

So let's setup parrot and close this issue? @tboerger @bkcsoft any idea?

@tboerger
Copy link
Member

tboerger commented Feb 5, 2017

Parrot doesn't support the ini format, so we most use weblate or something else

@bkcsoft
Copy link
Member

bkcsoft commented Feb 5, 2017

@tboerger Are you sure it doesn't?

@tboerger
Copy link
Member

tboerger commented Feb 9, 2017

@tboerger Are you sure it doesn't?

Yes, I'm sure: https://github.com/anthonynsimon/parrot/tree/master/parrot-api/export

@lunny
Copy link
Member Author

lunny commented Feb 10, 2017

It seems the interface is simple so that we can write an ini one using the same library with Gitea's configuration using.

@tboerger
Copy link
Member

It seems the interface is simple so that we can write an ini one using the same library with Gitea's configuration using.

That sounds good, so somebody should do that and we will see how long it takes to get accepted. But beside that I personally prefer MariaDB, this supports only PostgreSQL.

@lunny
Copy link
Member Author

lunny commented Feb 10, 2017

And maybe we should move this to v1.2?

@tboerger tboerger added this to the 1.2.0 milestone Feb 10, 2017
@tboerger tboerger removed this from the 1.1.0 milestone Feb 10, 2017
@tboerger
Copy link
Member

Parrot is pretty chaotic to setup, weblate doesn't directly support the ini format, so I have requested an OSS project on Crowdin and it have already been approved: https://crowdin.com/project/gitea

@tboerger tboerger modified the milestones: 1.1.0, 1.2.0 Feb 15, 2017
@lunny
Copy link
Member Author

lunny commented Feb 16, 2017

Does crowdin has an API?

@tboerger
Copy link
Member

Of course it got

@lunny
Copy link
Member Author

lunny commented Feb 20, 2017

So how should we copy TRANSLATION back to this repository?

@bkcsoft bkcsoft self-assigned this Feb 21, 2017
@bkcsoft
Copy link
Member

bkcsoft commented Feb 21, 2017

I'll look at integrating this during the weekend.

Seems like I need 2 commands, push and pull.

push

  • on merge master check if translations are updated
  • upload to CrowdIn

pull

  • check if translations have been updated
  • pull changes from CrowdIn
  • add, commit, push, create PR (why of course, nothing gets in w/o reviews 😂 )

@bkcsoft
Copy link
Member

bkcsoft commented Feb 21, 2017

further extension on push is if a translation other than en_US is changed

  • pull
  • apply change
  • if no merge-conflicts, add,commit,merge,PR

@bkcsoft bkcsoft removed their assignment Mar 26, 2017
@bkcsoft
Copy link
Member

bkcsoft commented Mar 26, 2017

I probably won't have time to check this in the near future

lunny pushed a commit to lunny/gitea that referenced this issue Feb 7, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

7 participants