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

using JuliaZH doesn't replace kw_str doc #41

Closed
Roger-luo opened this issue Oct 2, 2018 · 7 comments
Closed

using JuliaZH doesn't replace kw_str doc #41

Roger-luo opened this issue Oct 2, 2018 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@Roger-luo
Copy link
Member

I posted a MWE on discourse: https://discourse.julialang.org/t/cannot-replace-doctoring-in-projects/15805

@Roger-luo Roger-luo added the bug Something isn't working label Oct 2, 2018
@Roger-luo Roger-luo self-assigned this Oct 2, 2018
@ViralBShah
Copy link

Probably should go upstream to make translations first class.

@Gnimuc
Copy link
Member

Gnimuc commented Jan 29, 2019

It would be great if we could either use or emulate GNU gettext in Julia.

@Roger-luo
Copy link
Member Author

Roger-luo commented Feb 13, 2019

Yeah, but I think this is some issue related to some commit in 0.7, it worked in 0.7 for some period. I couldn't locate the bug however, dunno know why this happens yet.

@Roger-luo Roger-luo mentioned this issue Feb 13, 2019
@inkydragon
Copy link
Member

use or emulate GNU gettext in Julia.

Currently this library relies on Python's built-in gettext.py implementation via PyCall.
In the future, it may make sense to port this code into a Julia-native version (see Issue #1).

@Gnimuc
Copy link
Member

Gnimuc commented Feb 21, 2019

I guess the problem is no one would like to invest time to make this happen for now. Emulating gettext in Julia needs to hack into the Julia compiler, the first step is writing a Julep proposal. But the good news is we only need a PO file parser for supporting docstring substitution.

@Roger-luo
Copy link
Member Author

Yeah, agree with @Gnimuc I believe for most people after reading manual, they will be able to use most of the functionality and who is interested in development usually has the ability on reading English. We haven't had a large user group that requires such localization yet.

Other package/functionality can be in higher priority, so people have to work on other things first. Like me, my job queue is totally full for the next 4 month… So I would say we should wait for a while on this, and focus on manual first.

And on the other side, machine translation algorithm is growing fast, my friends are working on something related, they can analysis HTML directly (https://fanyi.caiyunapp.com). so I'm wondering if it's possible to integrate their application or things like Google translate directly. Then even new package developed in Julia will get i18n support.

I just asked their CTO about this. I'll update here if we get any further idea.

But again, I guess this won't influence much on the user experience. So not as urgent as manual part.

@Roger-luo
Copy link
Member Author

And the point for the original issue is that the doc string for keywords is not working after 1.0. it's definitely some kind of bug. Nothing related to gettext in this part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants