Translation process about gitea

[tboerger]

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

[joubertredrat]

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

[joubertredrat]

This sound suggestive 👍

https://github.com/anthonynsimon/parrot

[tboerger]

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

[bkcsoft]

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

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

[strk]

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

[metalmatze]

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]

@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]

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

[joubertredrat]

@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

"

[joubertredrat]

@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]

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

[joubertredrat]

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

[lunny]

I remember @tboerger has sent a request to Weblate?

[lunny]

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

[strk]

On Thu, Jan 05, 2017 at 07:06:02PM -0800, Lunny Xiao wrote: https://weblate.org/en/hosting/ @tboerger has you apply on this?

I've made a request but never got an answer. Never deployed it either so dunno how hard or easy it would be.

[Bwko]

We could host weblate on our own server

[joubertredrat]

Hi guys, I can host on my servers too.

…

-- "O que quer que você faça na vida, será insignificante. Mas é muito importante que você o faça... por que ninguém mais o fará." Gandhi "Whatever you do will be insignificant, but it is very important that you do it... because no one else will it." Gandhi

___________________________________________________________________ *Joubert "RedRat"* - Consultor em tecnologia - Technology consultant /me at Linkedin <http://br.linkedin.com/in/joubertredrat/> and Github <https://github.com/joubertredrat/> *~(,,">* RedRat Consultoria 2017-01-08 7:54 GMT-02:00 Bwko <[email protected]>:

We could host weblate on our own server <https://github.com/WeblateOrg/weblate/> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABczF5ObntS5fhZ5YsHT_9WELYACXrbXks5rQLJBgaJpZM4KsByg> .

[lunny]

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

[metalmatze]

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

[lunny]

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

[tboerger]

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

[bkcsoft]

@tboerger Are you sure it doesn't?

[tboerger]

@tboerger Are you sure it doesn't?

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

[lunny]

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

[tboerger]

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]

And maybe we should move this to v1.2?

[lunny]

Does crowdin has an API?

[tboerger]

Of course it got

[lunny]

So how should we copy TRANSLATION back to this repository?

[bkcsoft]

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]

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]

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