You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had a call with Eldad about console translation and there are some problems we need to discuss as a team and also as an Appwrite community 🤯 Please start a discussion so we have everyone's opinion and can make the right decision. ❤️
1. Do we translate exceptions?
Yeah, of course.. but let's think about it... Well, there is this problem that if someone shares an error code, people won't understand it and will not even try to help him... We will have to do more work on Discord not because people are lazy, but because people don't understand. The second reason is related to the second point below.
2. Do we make an API to add custom translations so people can translate their entire frontend with Appwrite?
Let's say we don't... We don't allow developers to translate frontend using Appwrite... What will they do? Well, they will use other tools (localazy, POEditor, ...) and translate it themselves. Well, back to the first question, do we translate exceptions? Why would we only translate some part of what their app is using? Do we force them to have translations split into 2 separate places?
Let's say we do allow it... Is this really what Appwrite is about? Aren't we getting too much out of the original focus of Appwrite?
3. Should we translate the words completed or waiting in execution status?
We could translate it so people understand the console better, but at what cost? New developer starts playing on the websites to learn stuff... Then he starts writing scripts and now he needs to learn even more stuff because we didn't already show him that status completed is actually something coming from API. If the word completed was not translated, he would be curious and right away he would think this has to do something with the code, not the language.
Let me ask a more general question: What phrases we don't translate? For example CLI, Unix, PowerShell or function.update... We don't translate these... Why would we translate status completed or trigger schedule? Where is the line?
4. Do we put HTML into translation files?
Here is an example:
By signing up, you agree to the Terms and Conditions and Privacy Policy
In HTML we actually have Terms and Conditions and Privacy Policy wrapper around <a> tag with target, href, class...
If we put it into translation, the translator might get confused. I have already seen cases when they actually translated words target or class...
If we don't put it into translation, what would the translation look like? How do we parse it?
We are only looking for some simple solutions... Do you have any experience from the past? Please share 🙏 If we don't find anything, it's fine, we will put HTML into the translation file and say that basic HTML understanding is required in order to contribute to translating Appwrite.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello team, hello Appwriters 👋
I had a call with Eldad about console translation and there are some problems we need to discuss as a team and also as an Appwrite community 🤯 Please start a discussion so we have everyone's opinion and can make the right decision. ❤️
1. Do we translate exceptions?
Yeah, of course.. but let's think about it... Well, there is this problem that if someone shares an error code, people won't understand it and will not even try to help him... We will have to do more work on Discord not because people are lazy, but because people don't understand. The second reason is related to the second point below.
2. Do we make an API to add custom translations so people can translate their entire frontend with Appwrite?
Let's say we don't... We don't allow developers to translate frontend using Appwrite... What will they do? Well, they will use other tools (localazy, POEditor, ...) and translate it themselves. Well, back to the first question, do we translate exceptions? Why would we only translate some part of what their app is using? Do we force them to have translations split into 2 separate places?
Let's say we do allow it... Is this really what Appwrite is about? Aren't we getting too much out of the original focus of Appwrite?
3. Should we translate the words
completedorwaitingin execution status?We could translate it so people understand the console better, but at what cost? New developer starts playing on the websites to learn stuff... Then he starts writing scripts and now he needs to learn even more stuff because we didn't already show him that status
completedis actually something coming from API. If the wordcompletedwas not translated, he would be curious and right away he would think this has to do something with the code, not the language.Let me ask a more general question: What phrases we don't translate? For example
CLI,Unix,PowerShellorfunction.update... We don't translate these... Why would we translate statuscompletedor triggerschedule? Where is the line?4. Do we put HTML into translation files?
Here is an example:
In HTML we actually have
Terms and ConditionsandPrivacy Policywrapper around<a>tag with target, href, class...If we put it into translation, the translator might get confused. I have already seen cases when they actually translated words
targetorclass...If we don't put it into translation, what would the translation look like? How do we parse it?
We are only looking for some simple solutions... Do you have any experience from the past? Please share 🙏 If we don't find anything, it's fine, we will put HTML into the translation file and say that basic HTML understanding is required in order to contribute to translating Appwrite.
Beta Was this translation helpful? Give feedback.
All reactions