-
-
Notifications
You must be signed in to change notification settings - Fork 163
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
Develop a translation workflow #35
Comments
I propose https://gitlocalize.com as a tool for translators to use. |
Thanks @MSakamaki! That looks great to me. Is this something you'd be able to set up for us?
You should have repo write access to be able to do the integration. After we get that set up, we should also reorganize the base template to be language-agnostic:
Markup like the analytics script, meta tags, and stylesheets are probably not going to change for each i18n page, so they are good candidates for the base template. Another open question is web fonts. We currently use Open Sans but I understand it might not be good for Japanese text. So maybe that should be included in the localized templates. Any ideas? Thoughts? |
Feel free to contact me for any help with Gitlocalize, ilya@gitlocalize.com |
Yes, I think I can help this.
I'm new to Flask and Python. I'm in the midst of exploring how to do this in a cloned repository. |
Thanks @MSakamaki. The
Hmm does this mean we'd need to manually extract every word from the English contents and put it in a yaml or json file? Is the translated version a similar map of words to translations? If so does that mean that we'd need to have a build process to reconstruct the content from the translations? cc @ilyaspiridonov I was hoping that we could write HTML templates and markdown files, which Gitlocalize picks up and generates translated versions of the HTML templates and markdown files. |
At first I was thinking about a mechanism to translate dynamically from keywords. The point of concern is that the process of extracting words from json can interfere with site construction. And there are performance concerns.
I think this idea is good, deploy in the contents directory both the html need to translate and the markdown. I examined the characteristics of flask, and realized that all the html templates need to be placed in the tempalte_folder. So, if you want to include html in the target of translation, |
How reliable is word-for-word translation? For example, idioms and phrases might be best translated in groups of words or entire sentences. Also, things like pluralization rules are different across languages. So it would seem like replacing the entire document with a translated version (as opposed to individual translations for each word) would be more reliable.
Good point about Flask requiring the So maybe something like Then in the handlers for each page, we check for a locale and insert it into the template path: @app.route('/')
def home():
return render_template('en/index.html')
@app.route('/ja/')
def home_ja():
return render_template('ja/index.html') Could look into a way to do this dynamically while validating language codes. |
Thank you for Flask's easy-to-understand example! I am concerned that if HTML is included in the target of translation, the layout may be broken. Yes, words can be inconsistent with context, and including html can break the layout, which we consider to be a trade-off. (In either case, it is necessary to check the final layout) |
Ah I see in https://github.com/HTTPArchive/almanac.httparchive.org/blob/translation-spike/src/templates/index.html how you've implemented what you're describing. I'm reluctant to go with that approach because even for the English version it requires mapping text to variables, which seems like a cumbersome way to write HTML. After all of the English content is written how easy is it to copy/paste all of the content to a
This is a good point. We don't want to repeat every HTML change N times for N languages. I'm hoping that things like the layout will be stable by the time we're ready to start translation late in the project. If we need to choose between a build time or run time word/phrase substitution approach, I'd much prefer a built time approach so it doesn't impact the UX. |
Thanks for the answer! I was able to understand your opinion. Certainly, there may be layout conflicts and translation conflicts after site construction is complete, but the impact may be minor. I think that the create issues is good when there is a problem with the copy of the translation html. I agree to |
There is one question, is this translation like a langage(en/ja)? Or do think it is better to be aware of the location(en-US/ja-JP)? |
Good question! Could you explain more of the benefits of including the region in the language code? Do you anticipate having multiple regions per language or is it motivated more by being precise/explicit with the intended reader of the translation? We can also name the directories short codes like |
Yes, I thought it would be nice to add localization code to the directory so that not only readers but also translators at start-up can be made explicit localization aware. As I am not familiar with the idea of translation solutions, there may be some wastes or problems with this idea. |
Sounds good, let's add the location to the directory. |
This problem has been resolved now, I'm will try to integrate gitlocalize.com. |
I'm sorry, I have checked at gitlocalize.com integration, there was one problem. found that setting of locale code (en-US) seems to be difficult in directory unit.
For now, I'm thinking about the approach of 1. |
Hi there, this is Ilya from GitLocalize. |
Thank you for answer! In my think, glad that there is a locale code, but it was not required. If it is possible to integrateion with gitlocalize.com simply by removing the locale code, I think it is better to start with language code only. @rviscomi @ilyaspiridonov jinja template Markdown, html, yaml seems to support. |
@MSakamaki I think approach 1 is the best option. |
Agreed, let's remove the locale from the directories for now. Filed this PR to do the renaming: #43. Curious to hear more about Jinja compatibility with gitlocalize. |
@MSakamaki @ilyaspiridonov is it possible to use gitlocalize with Jinja templates? |
@rviscomi I forked this repository and added jinja templates, simple html, and markdowns. Here you can try out the gitlocalize behavior of it. If the solution is not given by @ilyaspiridonov and you use gitlocalize.com, the translation of jinja templates will be PR based. OtherIf want to translate all content in the same experience, you may need to unify it into a PR-based update or submit a community application to crowdin. This is a sample created with the crowdin trial account. |
How about we do manual PR-based translations for all of the Jinja-based content, and when we have the chapters written we use markdown for them and gitlocalize to do the translation. Does that work? cc @mikegeyser this is related to #59. |
Okay, copying html by hand is a bit cumbersome, but I think that there is no serious problem.
Yes, as soon as we have a markdown content in the en-US directory, i are ready to integrate it. I want to confirm one. |
Naming branches |
The web server should accommodate multiple languages. See #29 for context.
To summarize the thread:
Original comment for reference:
I think we should create a
src/en/
directory and put all of the English-specific templates there by default, including our current splash page.So the directory structure might look like this
In src/main.py we should use the
en
directory by default, unless one is specified in the URL and it's a supported language code.We also need to start thinking about (but not necessarily implement at this stage) a way to switch languages in the UI.
@HTTPArchive/developers any takers for this issue? Any other implementation ideas?
The text was updated successfully, but these errors were encountered: