-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add i18n support to RStudio #1
base: master
Are you sure you want to change the base?
Conversation
Includes basic properties, but probably not a good workflow
Was this duplicate command intentional? If yes, need to handle this in i18n properties/interface generator scripts
…perties Really this makes more sense to be separate scripts or have a more modular entrypoint, but haven't done that yet.
- rearranges parsers and helpers to reduce duplication - adds (untested) menu parser - fix Command tests
…o other types * Add lineage of element to Menu item names in output constants/properties file (eg: File->NewFile->R is now named "menu$File$NewFile$R") to resolve naming collisions * Use lxml instead of ElementTree to support identifying parent from XML elements * Add ElementParser.grep_from_element_tree() to encapsulate element search logic somewhere transferable (finding menu items is different from shortcuts, commands)
* Add i18n support for MenuEmitter * Add MenuConstants.java/MenuConstants_en.properties (generated by xml_to_i18n.py) * Refactor CommandConstants interface to CmdConstants to be consistent with xml tagging nomenclature. Rename files generated using xml_to_i18n.py
Shortcut is working in progress. Realized we need to also handle the if statements (refid alone is not enough - any combination of refid+if is a translatable string). If statements have many possibilities (`if x.y.z.isMac() && isFirefox()`, etc) and can be generic so we don't know what'll be added later. These are typically outlined in `org.rstudio.core.client.BrowseCap` and `org.rstudio.studio.client.application.Desktop`. Need to consider this more. Might be able to just concatenate refid+if then convert to only valid class name characters. Is that workable? It'll make for terrible class names in the interface/properties file, although maybe we could annotate them with better data in the comments
…cription Updated generate-prefs.R to emit i18n constants and properties files and to use those in the emitted Prefs/State accessor classes for title and description. Code appears to be working, but I cannot find where these titles/descriptions are actually used. I thought they'd be in the Global Options menu, but those menus are described by static strings in the menu definitions. I cannot find anywhere else these titles/descriptions are used for.
…mbers) * Adds signatures to numericPref and checkboxPref that parse the preference Title and Description and pass them to the element in the Pane. Some text in the EditingPreferencesPane has been ported to the user-prefs-schema.json because it is more descriptive * Above signatures add tool tips to any option that has a description in the users-prefs-schema.json file. This adds tooltips to many options that previously did not have them. Most Titles/Descriptions are the same or very similar to the static strings that were in EditingPreferencesPane before, but some have slight changes. Need to check whether there's any material reversions that have occurred. Enumerators and statically defined headings are still todo
Intermediate update: I plan to clean it up and make it more approachable, but for now the basics that have been done are:
The new i18n for Outstanding items/questions:
|
* Add human readable text corresponding to enumerators in user-prefs-schema.json. Add handling of these in generate-prefs.R to export human readable enumerators to translation files/use those translations instead of hard coded text in EditingPreferencesPane.java. * Add convenience signatures to SelectWidget * Convert EditingPreferencesPane.java's SelectWidget's to i18n * Remove CommandConstants.properties file that should have been removed previously * Minor updates to user-prefs-schema.json to reconcile differences with hard-coded strings in EditingPreferencesPane.java
Adds PreferencesPaneConstants properties, interfaces
CRANMirror implements a .getDisplay() method for showing a human readable representation of itself. PackagesPreferencesPane.java and ChooseMirrorDialog.java both use this, but only when CRANMirror.host != "Custom", instead showing CRANMirror.url in this case: * These two references are the only usages of getDisplay(), and are direct copies of each other. Both apply the same logic in whether to use getDisplay() or create their own displayed text, and when creating their own displayed text they produce the same result (using the URL as the display value * Determining whether a CRANMirror is "Custom" depends on the somewhat brittle fact that .host=="Custom" when a mirror is defined by URL alone. This is hard for the CRANMirror maintain if it was ever updated (need to find hard coded strings of "Custom" in the codebase and update them) Proposed changes here address the above by centralizing the display logic of PackagesPreferencesPane.java and ChooseMirrorDialog.java in CRANMirror. The following added/changed methods are provided in CRANMirror: * .getCustomEnumValue(): Serves as an enumerator to specify the string label that denotes a custom object. This would be more cleanly implemented as an enumerator string, but CRANMirror extends JavaScriptObject which cannot have class-level attributes * .getSecondaryEnumValue(): Similar to Custom, but implements another enumerator for a "Secondary" mirror * .setAsCustom(): This sets the object as a "Custom" (url-only) object, replacing the previous pattern where the user of the object would set .host="Custom" and .name="Custom" themselves * .isCustom(): API for public to assess whether a CRANMirror is or is not "Custom". Implemented by testing `host==getCustomEnumValue()` (eg: host=="Custom"), which is how consumers of this object previously performed the test themselves * .getDisplay(): Implements the logic used by PackagesPreferencesPane.java and ChooseMirrorDialog.java, where the display text will be the URL if this is a custom CRANMirror.
WIP PR for adding i18n support to RStudio. Will fill this issue out with a better task list shortly.
i18n tasks:
Commands.cmd.xml
:user-state-schema.json
/user-prefs-schema.json
generate-prefs.R
to emit java/gwt constants/properties filesenumReadable
touser-prefs-schema.json
to contain human readable "enum" text that should be translated (this is used as the display text for selection boxes in Global Options menus - eg: enum optionquotes_and_brackets
hasenumReadable
ofQuotes & Brackets
).java
definitions)Options -> Code
(EditingPreferencesPane.java
)user-prefs-schema.json
to prevent duplicate text/translation effort (existing code has text hard coded here plus defined in the.json
)LineEndingsSelectWidget
class. It implements the enumerator and human readable values directly, plus logic for whether to show all values or a subset. This class is also used byProjectEditingPreferencesPane.java
, which does not have the same access to preferences asEditingPreferencesPane.java
. Need to investigate. Porting logic will be easy, but getting the translated values from thelineEndingConversion()
PrefValue
might be harder.Options -> *
)