Closed seanforyou23 closed 6 years ago
This looks great! I can't think of any details you missed. I'm really glad the long-term plan is extract all text in the UI from the doc source files.
Regarding steps [1] and [3], we should store all dictionary entries in a single JSON file. There're several arguments for that:
{
integration: "Integration",
brand: "Syndesis",
uses: "This {integration} has been used {0} times in the {brand} application."
}
This renders: This Integration has been used X times in the Syndesis application.
{
integration: "Integración",
brand: "Syndesis",
uses: "Esta {integration} ha sido utilizada {0} veces en la aplicación {brand}."
}
This renders: Esta Integración ha sido utilizada X veces en la aplicación Syndesis.
Please notice the divergences between placeholder lcoation. You get the drill... Please also notice how we will want to inject the X amount of uses dynamically.
The above can only be accomplished when handling a single file. Otherwise we might run into racing conditions. In regards of implementation from an UI POV, we will want to provide:
[innerHtml]
attribute in the form of a directive that wraps syntactic sugar around said attribute to avoid having to use the aforementioned pipe inside that attribute.I have already developed an implementation of all the above, and am just waiting for clearance, 3 working days and a working environment to get this done.
Great points @deeleman, it's been a while since I implemented translation dictionaries, and last time I did it was in a multi-page application so I'm sure techniques have changed a bit since then :) Given your experience and interest in this, I'd like to work with you more on the actual UI implementation to ensure it's built well fashioned.
The tooltips.json is just stepping stone toward this bigger goal. So not suggesting multiple documents for different kinds of text, just a single document in the many supported language/local combos as you described above. So tooltips.json
will likely become text-content.json
or something of the sort.
Here's an example of a well structured translation document - just for reference https://cdn.karjalakasino.com/dictionaries/en-gb.json
Anyway, good to know we have some direction for implementation!
Just want to note here that I discussed this with some of the other Fuse writers today. Maybe the better solution is simply for a doc person (just me for now) to directly update the product source files. This is open source, right ? :-) The original premise was that text in the UI duplicates text in the guides we provide. But in reality, it is rare that text in the doc source is the exact text that we want in the UI. So, after GA, let's talk before anyone does any more work on this.
Maybe the better solution is simply for a doc person (just me for now) to directly update the product source files.
Would you feel comfortable editing the texts in a JSON file? I think it is the best way forward.
With this being said, I self-assign this issue to myself. Hopefully will get a POC or even the entire site localized in a couple of days.
I am not in today but I am definitely comfortable editing Json files and I already requested two PRs that were merged for the FTP and drop box connectors so please do not do a lot of work here. I definitely think that the better solution is for me to edit the source strings directly
Just want to note here that I talked with Michael S. about the feature Pablo coded and I am all for the dictionary json file. I can edit that file instead.
@TovaCohen I'm putting together a comprehensive tutorial about how to manage text strings through the dictionary file with guidelines for both content editors and frontend developers about how to approach and take advantage of this implementation. I'll merge it today, so I'd recommend everyone involved in this endeavor to hold off before editing the master dictionary files. Thanks :)
This is a...
The problem
The problem is that currently all of the text used within the UI is hard coded in template/controller files. This blocks us from doing two important things
1) Driving tooltip text from the actual docs as made possible in https://github.com/syndesisio/syndesis/pull/1369
2) Supporting internationalization and localization
This issue is an evolution of https://github.com/syndesisio/syndesis/issues/295, and is meant to encompass all the site text, and not just tooltip content. Having all the language used in the site scattered across many files makes updating text time consuming and difficult.
Expected behavior
The UI should never use literal text strings, but instead use a mechanism (probably a language service) that allows one to specify string keys, which in turn generate the appropriate text at runtime.
This will help improve consistency of the language used within the app and also speed up time required to update text on the site by moving power of control over to those who should have it in the first place.
Related Issues
https://github.com/syndesisio/syndesis-documentation/issues/20 https://github.com/syndesisio/syndesis-documentation/issues/23 https://github.com/syndesisio/syndesis/issues/295
API Endpoints and Schemas
doc/tooltips/tooltips.json
Tasks involved / Steps to Reproduce
doc/tooltips/tooltips.json
and negotiate key names with @TovaCohenI can see number 3 above becoming quite a large work item, so it may make sense to turn this into an Epic and break the task down into more manageable chunks. I'll let someone else make the call as to how best we can divide up this work.