Community
Participate
Working Groups
Could someone take a look at this string? technology.egit4693566: AbstractFetchFromHostPage_ContentAssistTooltip Press '{0}' to see a filtered list of {0} It seems weird to have {0} twice... It belongs to the new "merge requests from Gitlab" dialogue. It looks OK with both en and en_AA locales ("Press ctrl-Space for merge..."), but not when translating for es (does something like "Press merge... for merge..."). I'm using new eclipse 2021-12 with 12/12 babel nightly translations. Amazingly, the Ctrl-space does OK with en/en_AA but seems to be ignored when using es locale. David
...may have to do with ¿this?: https://git.eclipse.org/r/plugins/gitiles/egit/egit/+/4602dc5242803be8ff02fa148a7fcc1984706d46%5E!/ commit 4602dc5242803be8ff02fa148a7fcc1984706d46 [log] [tgz] author Thomas Wolf <thomas.wolf@paranor.ch> Sat Oct 02 22:04:51 2021 +0200
File: org.eclipse.egit.ui/org/eclipse/egit/ui/internal/uitext.properties String: AbstractFetchFromHostPage_ContentAssistTooltip=Press '{0}' to see a filtered list of {0}
EGit team, please take a look.
@David: make sure the single quotes around the first {0} are kept.
Done in Babel tool... I'll check with tomorrow's build. In case it's fixed I may need some help to understand this, sniff. David
Due to the internal structure of EGit, the message is processed twice. The single quotes escape the first {0} so that it is not replaced during the first processing. The first time, we add "merge requests" or "pull requests", and the single quotes are removed. So after the first processing, we have Press {0} to see a filtered list of merge requests. The second processing then replaces this remaining {0} by the key binding.
(In reply to Thomas Wolf from comment #6) > Due to the internal structure of EGit, the message is processed twice. The > single quotes escape the first {0} so that it is not replaced during the > first processing. The first time, we add "merge requests" or "pull > requests", and the single quotes are removed. So after the first processing, > we have > > Press {0} to see a filtered list of merge requests. > > The second processing then replaces this remaining {0} by the key binding. @Thomas, that's interesting. That's not a normal Java MessageFormat processing. Is this special process being used in all EGit strings? I saw another string with {0} and {1}. Is that okay? File: org.eclipse.egit.ui/org/eclipse/egit/ui/internal/uitext.properties String: CommitEditor_couldNotGetTags=Could not get tags for commit ''{0}'' in {1}
(In reply to Kit Lo from comment #7) > @Thomas, that's interesting. That's not a normal Java MessageFormat > processing. The use of single quotes to escape something is standard MessageFormat. See its javadoc. It's also the reason why one has to write a doubled single quote to get a single single quote in the processed string. > Is this special process being used in all EGit strings? I saw another string > with {0} and {1}. Is that okay? No, it isn't used for all messages. Ithink this one may be the only one where we do that.
(In reply to Thomas Wolf from comment #4) > @David: make sure the single quotes around the first {0} are kept. Tooltip text now displays as expected. But "Ctrl-sapce" does nothing when using "es" locale (en/en_AA display three merge requests in my Gitlab repository using the same workspace, same egit environment). David
(In reply to David Martin from comment #9) > (In reply to Thomas Wolf from comment #4) > > @David: make sure the single quotes around the first {0} are kept. > > Tooltip text now displays as expected. But "Ctrl-sapce" does nothing when > using "es" locale (en/en_AA display three merge requests in my Gitlab > repository using the same workspace, same egit environment). > > David That then seems to be a different problem. EGit calls IBindingService bindingService = Adapters .adapt(PlatformUI.getWorkbench(), IBindingService.class); bindingService.getBestActiveBindingFor( IWorkbenchCommandConstants.EDIT_CONTENT_ASSIST); to determine the trigger sequences for that command, and if it's a single trigger sequence which is a Keystroke, shows that keystroke. I don't know why that keystroke would not invoke content assist. Is there some other binding for Ctrl-Space?
(In reply to Thomas Wolf from comment #10) > I don't know why that keystroke would not invoke content assist. Is there > some other binding for Ctrl-Space? I'm sorry I can't help any more. I have no experience in debugging eclipse… Ctrl-Space is widely used in eclipse and so far it's working properly for me elsewhere. Even in the neighbour egit "pull..." dialogue it displays existing branches. I've checked key bindings and this is the only one for Ctrl-Space; I've also restored it! And I'm using the same workspace across different locales so that settings are all the same. I am using the zip/tar version of eclipse (ubuntu) with babel files unzipped to the dropins folder. Internal and external JREs… I've done a separate installation under W10 with just the egit babel file and a new git folder. Tried French… It's just with the Spanish locale that it fails. There must be a secondary side effect somewhere. Finally, I did a last check creating a github pull request on my own repository. Here the Ctrl-space worked, but the finish button was responsiveless despite being active… I couldn't reproduce this under W10 as I didn't get there the download Github PR menu option for this repository. It's weird that a translation set is causing such misbehaviour! It shouldn't that harmful! David
(In reply to Thomas Wolf from comment #10) > (In reply to David Martin from comment #9) > > (In reply to Thomas Wolf from comment #4) > > > @David: make sure the single quotes around the first {0} are kept. > > > > Tooltip text now displays as expected. But "Ctrl-sapce" does nothing when > > using "es" locale (en/en_AA display three merge requests in my Gitlab > > repository using the same workspace, same egit environment). > > > > David > > That then seems to be a different problem. EGit calls > > IBindingService bindingService = Adapters > .adapt(PlatformUI.getWorkbench(), IBindingService.class); > bindingService.getBestActiveBindingFor( > IWorkbenchCommandConstants.EDIT_CONTENT_ASSIST); > > to determine the trigger sequences for that command, and if it's a single > trigger sequence which is a Keystroke, shows that keystroke. > > I don't know why that keystroke would not invoke content assist. Is there > some other binding for Ctrl-Space? You may be right: it "seems to be a different problem". And it's likely to be my fault... I checked the error log for both the Ctrl-Space (Gitlab) and the finish button (Github): Unhandled event loop exception -------- java.lang.IllegalArgumentException: Unmatched braces in the pattern. at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:521) at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371) at java.base/java.text.MessageFormat.format(MessageFormat.java:860) at org.eclipse.egit.ui.internal.fetch.FetchChangeFromServerPage$PullRequest.getProposal(FetchChangeFromServerPage.java:197) at org.eclipse.egit.ui.internal.fetch.AbstractFetchFromHostPage.lambda$12(AbstractFetchFromHostPage.java:1253) at org.eclipse.egit.ui.UIUtils$2.getProposals(UIUtils.java:597) at org.eclipse.jface.fieldassist.ContentProposalAdapter.getProposals(ContentProposalAdapter.java:2033) at org.eclipse.jface.fieldassist.ContentProposalAdapter.openProposalPopup(ContentProposalAdapter.java:1880) at org.eclipse.jface.fieldassist.ContentProposalAdapter$1.handleEvent(ContentProposalAdapter.java:1734) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) ... ------------ java.lang.IllegalArgumentException: Unmatched braces in the pattern. at java.base/java.text.MessageFormat.applyPattern(MessageFormat.java:521) at java.base/java.text.MessageFormat.<init>(MessageFormat.java:371) at java.base/java.text.MessageFormat.format(MessageFormat.java:860) at org.eclipse.egit.ui.internal.fetch.AbstractFetchFromHostPage.doFetch(AbstractFetchFromHostPage.java:993) at org.eclipse.egit.ui.internal.fetch.AbstractFetchFromHostWizard.performFinish(AbstractFetchFromHostWizard.java:59) at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:832) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:472) at org.eclipse.jface.dialogs.Dialog.lambda$0(Dialog.java:619) at org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:84) ... -------------- And guess, there was a faulty translation for key GitServer_MergeRequestContentAssistLabel having impaired brackets! Let's see if I can confirm the resolution with tomorrow's Babel builds. David
(In reply to David Martin from comment #12) > And guess, there was a faulty translation for key > GitServer_MergeRequestContentAssistLabel having impaired brackets! > > Let's see if I can confirm the resolution with tomorrow's Babel builds. > David Oi! Babel does not validate message syntax? It could at least warn about message strings that do not conform to the MessageFormat, NLS, or slf4j syntax. (If it wanted to be "smart", it could suppress the warning if the untranslated string already does not conform to these syntaxes -- in that case, the application likely is not going to feed the message to either MessageFormat, NLS, or Logger.) Or if such syntax checks are too complicated, it could at least warn about unmatched curly braces.
Ctrl-Space is done, getting Gitlab merge requests. "Finish" buttons, for both Github and Gitlab requests persist in failing. I found two more "{0]" mistakes: AbstractFetchFromHostPage_GetChangeTaskName: "Get {0}" (egit) ExportLaunchConfigurationsWizardPage_12:"Would you like to overwrite {0}?" (eclipse) ...so, expecting next build. I agree that some basic testing for translated strings would be helpful, at least when these string may cause such damage. On the other hand, I would suggest to try some refactoring on the '{0}' trick, using a "classic solution" based on numbering parameters {0}, {1}... The "'{0}'" doesn't seem to me very "translators friendly". I was doing some search and it is used one single time, at least in the last 20000 strings starting like "Press XXX". Please, consider that quoting is a key issue in l10n, using different characters and policies in different languages. David
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/189114
(In reply to David Martin from comment #14) > On the other hand, I would suggest to try some refactoring on the '{0}' > trick, using a "classic solution" based on numbering parameters {0}, {1}... > The "'{0}'" doesn't seem to me very "translators friendly". I was doing some > search and it is used one single time, at least in the last 20000 strings > starting like "Press XXX". Please, consider that quoting is a key issue in > l10n, using different characters and policies in different languages. I wasn't aware that using this standard mechanism (for both MessageFormat and NLS) was troublesome for translators. They have to know that single single quotes escape things. (And that a message having a single single quote that is _not_ used for escaping like "Don't do this" is likely to be wrong -- it'll be rendered as "Dont do this", so it should be "Don''t do this".) (In reply to Eclipse Genie from comment #15) > New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/189114 This changes the message to "Press {0} to see a filtered list of {1}" and then replaces {0} by "{0}" in the first processing, which has the same effect as the '{0}'.
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/189114 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=151e91f232264dd860c285625bf5198609bea09b
