-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Tamil pages proof of concept #2512
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
Conversation
sbrl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, @arunisaac!
The next step is client support. The official node client is over here - which looks like a good place to start. We should probably define a common 'specification' for how it's going to be implemented in clients - I think we had an issue for that somewhere.
Is there an environment variable that we could use to auto-detect?
|
Great work, @arunisaac!
Thanks! :-)
We should probably define a common 'specification' for how it's going
to be implemented in clients - I think we had an issue for that
somewhere.
Is there an environment variable that we could use to auto-detect?
How about using gettext's conventions?
https://www.gnu.org/software/gettext/manual/html_node/Locale-Environment-Variables.html
gettext also has means to specify a priority list of languages. See
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html
|
|
This is the issue. Please comment on it so that we have everything at one place. |
|
Shall this PR be blocked on having at least one client support the translated pages, or the other way around? |
|
I this it is the other way around. Clients cannot support translated pages, if this PR is blocked. |
|
If everything is fine, can this PR be merged? It would be easier to work
on client support if this PR is merged.
|
|
Merged! I agree that client support is much easier to deal with if we merge this PR - we can always revert it if need be :P Also, I've guessed a standard PR / commit message format: |
Actually @arunisaac specifically asked if the pattern he had used for individual commits ( |
|
On a separate note, I'm sad that @arunisaac's care with separating the commits was not reflected in the final merge into the master branch. The maintainers' guide suggests that:
But I guess all these guides and documentation are becoming too verbose and more of a burden than helpful cheatsheets for day-to-day operation of the project. Or maybe it was my fault to propose them and not stick around for long enough to ensure they get assimilated into the maintainer culture (as other principles did). In any case, I hope @arunisaac does not get discouraged from making atomically separated commits in the future :) |
|
Oops! I think I missed both those points. On second thought, it would have been a better choice to rebase here rather than squash - I haven't rebased in ages on here! I'll try and consider this more in the future. I can revert & re-merge here if you like? This conversation has gotten rather long here and in #2339, so I think I missed the bit on the commit message standardisation too. |
|
In terms of guides & documentation:
|
Yes it's rare. But I rebase from time to time, when I see good commits. Regarding, commit message, I think we should update the PR template too. Since that mentions how a commit message should be. |
|
In any case, I hope @arunisaac does not get discouraged from making
atomically separated commits in the future :)
No, since you mentioned it, I won't be discouraged. :-)
Regarding the commit message format, I have no strong opinions. Perhaps,
I slightly prefer `cp: add Tamil page` to `cp: add Tamil translation`
since the former is slightly shorter.
|
That would make the history even messier IMO. The only way to fix it would be to force-push to the master branch, but that's a pretty huge hammer that I don't think is justified in this case.
That's a fair point, but IMO the 5 characters that we save are worth less than the extra clarity (not everyone knows the name of all languages in the world). So my preference still remains
I'm not sure the maintainers guide is the best place for that. Or do you mean the commit message format? Though even then, I think the general CONTRIBUTING.md guide would be a better place, don't you agree?
Good point. Once we decide on the format, let's update that too. |
|
Yep, |
|
@arunisaac - thanks for this. It's really great to see tamil translations to oss projects. |
|
Thank you! :-) It would be nice to have many more translated pages,
though. I haven't worked on this in a long time. Do contribute
translations if you find time.
|
This is a proof of concept for Tamil pages as discussed in #2339
The page (if new), does not already exist in the repo.
The page (if new), has been added to the correct platform folder:
common/if it's common to all platforms,linux/if it's Linux-specific, and so on.The page has 8 or fewer examples.
The PR is appropriately titled:
<command name>: add pagefor new pages, or<command name>: <description of changes>for pages being edited.The page follows the contributing guidelines.