I had liferay 7.0, when you open the ispect ( Ctrl + Shift + I) then go to the console and write
for english
Liferay.Language.get('login');
"Login"
german language
Liferay.Language.get('login');
"Anmelden"
But Now when I upgraded to Liferay 7.4 , I get
for english
Liferay.Language.get('login');
"login"
german language
Liferay.Language.get('login')
"login"
The issue has been reported
https://issues.liferay.com/browse/LPS-123191?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
https://help.liferay.com/hc/en-us/articles/4403607020813-Liferay-Language-get-method-is-no-longer-working-with-string-variables-as-of-DXP-7-3
From one of the comments in the tickets that you've linked yourself:
That option was deprecated under LPS-113569 and is no longer available. You can get some extra information in the pull request deprecating such functionality:
Liferay.Language.get is replaced by the language filter and we also want to remove the AUI dependency, so in this change, we migrate the Liferay.Language.get function to frontend-js-web.
Note that the migrated version is dumbed down to just return the key: it does not preserve the dubious fallback behavior of the old implementation, that used a deprecated synchronous request to the server to fetch the value, which would produce a console warning, and very likely end up returning the key anyway (unless the corresponding value happened to be in the kernel); in short, the old implementation only wallpapered over a real problem (failure of the filter to do its actual job).
One of the linked issues is about updating the documentation, which hasn't happened yet.
Edit, following your comment:
The documentation that you link in your comment looks like the not-yet-updated documentation.
In general, I've confirmed your statement (which wasn't a question, by the way): Indeed, the feature you've been using has become less and less useful (as it was only good for a few translations from core, never from any module, and retrieved them in a performance-killing way. It's not possible to extend it to retrieve all modules' keys and do so in a performant manner, so you should use whatever technique the libraries you're using to translate your frontend are using)
In case you're building your UI with JSPs, that would be <liferay-ui:message key="your-key-of-choice"/>. In other cases, you know what you're using, and that framework definitely has means of providing localization.
yes, this is true it does not work anymore, as Olaf Kock said , you need to implement a new way to localize javascript , there is a npm tool for this #clavis/translation-transformer
Related
We currently have Two Factor Authentication working in the 2017_2 release of the NetSuite PHP Toolkit, but we have some code that has broken due to changes between 2015_2 and 2017_2. It seems that in 2017_2 it is also far easier to set up Two Factor Authentication.
Looking at the code, however I do see references to TokenPassport and TokenPassportSignature, which tells me that I should be able to get TBA working in 2015_2, which would give us time to figure out the rest of the issues.
My question is: How would I actually go about that? I have set $service->passport to the generated TokenPassport object. I know that my TokenPassport object works in 2017_2, and I assume it would be the same, but I don't know for sure, and I can't seem to find any information up on Elgoog.
ETA: I have seen examples of this working in 2015_2 in Ruby, but not in PHP. The backend is there, but I can't seem to be able to do this in PHP, and the Ruby examples were only snippets.
Okay, so I solved this for myself, but I may not have done it the "right" way. Here's what I did:
I took the makeSoapCall and setTokenGenerator methods from the new instance of NSPHPClient.php, and I added them to the OLD version. I had to modify the setTokenGenerator method to not require an instance of iTokenPassportGenerator, but I could have just as easily copied over that interface as well.
Basically, all that needs to happen is that we need to send the tokenPassport header, which the older version of the SDK can generate but doesn't have a method to actually send that I could find.
Gmap.addoverlay() causes map to zoom out if you've called getEarthInstance().
Using ge plugin 6.2.1.6014, Chrome/Mac OSX and {Firefox,Chrome}/Windows Vista Home Premium (Cross-posted on Google Earth API issues). See the test code here.
Shortly after the second marker appears, the maps zooms out, even though noone asked it to.
By putting an alert() in that callback and extending the timeout() interval, I'm pretty sure it's the addOverlay(), not the getEarthInstance(), where the problem occurs.
To immunize my code, I tried the commented code in the callback, but it's apparently too late by then.
So, is there any way to determine the version of the plug-in without calling getEarthInstance()? Perhaps some hacking with google.load? Without a clean way to detect the version of the plug-in, I'd have to disable the G_SATELLITE_3D_MAP as long as any of this version of the plug-in remain installed out there, which, I'm thinking, is pretty much forever?
I'm calling getEarthInstance() because I want to enable a few layers and set a click listener on the globe. Is it possible to do either of those things without getEarthInstance()?
I haven't used v2 of the Maps API extensively, so maybe this is a long-known behavior, but this does appear to be a bug. I suggest filing it on the Maps API v2 issue tracker, as the plugin itself (or the plugin API) can't really do anything to change the view of the map.
Please note that v2 of the API has been deprecated (since May 2010!), so they are only fixing regressions. Also, you should really consider switching to v3 of the API; there's even a handy library for Earth API integration.
In the meantime, there are a few approaches that might help:
Is there a reason that you're checking the version number of the
plugin? There have been some additions to the API in recent
releases, but I'm not sure what in 6.2 would be a deal-breaker. The
plugin has used the same auto-updater as Google Earth for some time
now, so the vast majority of users are on the latest version of the
plugin anyway. There are a handful of holdouts on 5.x and 6.0 for
specific reasons, but there really aren't very many. For almost
everyone that visits your site, the isSupported() check should be
sufficient, and if it isn't, they have probably purposefully opted
out and know why things aren't working.
Since you're loading the earth Javascript library anyway, you can
consider just loading an instance of the plugin without involving
the API. google.earth.createInstance will help you out there
(you can use a hidden html element if that matters, just make sure
to detach it and let it be garbage collected when you're finished).
There is some overhead in starting up a plugin instance and then
discarding it, but it's pretty minor over just starting it, which
you're already doing here. The next plugin instance will also be
created more quickly when the view is switched to 3D.
To anyone who's been hit by this bug, thanks to the suggestion in the answer by Mr. Kenny, here's some code to check the plug-in version without falling victim to the bug we're trying to avoid:
function enable_geplugin(map, div, callback) {
if (!google.earth.isSupported())
return;
var earth_div = document.createElement('div');
document.body.appendChild(earth_div);
earth_div.style.height = '1px';
earth_div.style.width = '1px';
google.earth.createInstance(
earth_div,
function(instance) {
if (!instance.getPluginVersion().match(/^6\.2\./)) {
map.addMapType(G_SATELLITE_3D_MAP);
if (callback)
map.getEarthInstance(callback);
}
earth_div.style.display = 'none';
document.body.removeChild(earth_div);
},
function(errorCode) {
// do this so user can click on map type "Earth" and see the download instructions
map.addMapType(G_SATELLITE_3D_MAP);
earth_div.style.display = 'none';
document.body.removeChild(earth_div);
}
);
}
Used, for example, here.
(On OSX/Chrome, the document.body.removeChild(earth_div) generates an Uncaught ReferenceError: NPObject deleted, but that's the least of my worries.)
So we can now effectively disable G_SATELLITE_3D_MAP for bad plug-in releases, but I still hope someone working on the plug-in fixes the bug itself.
Does anyone have a link to a concise summary of what makes a portlet "JSR-286 compliant" vs being only "JSR-168 compliant". I've got a copy of the spec and that's anything but concise so linking the spec is not a useful answer. I've searched the web for an hour now and I've found nothing that is clear (aside from the spec, which of course requires that you read the previous spec too, and then weed out the "new features" from the "required compliance".
Particularly I've found that there's quite a bit of confusion out there on the necessity of web.xml, which appears to come from people using Liferay and not realizing that Liferay is dropping in a web.xml for them.
Do JSR-286 portlets require a web.xml file in their WAR files?
What I'd really like is something that contains one or more of the following lists:
Things you have to do to a JSR-168 to make it become JSR-286 compliant
Things you must not do, that would cause an otherwise JSR-286 compliant portlet to be considered only JSR-168.
You can leave "use the portlet-app_2_0.xsd" off the list, as I consider that part obvious.
I'm open to the answer that both lists are empty aside from the DTD/xsd for portlet.xml, and the difference is only in what the portal supports, but please back that assertion up with a link or other reference.
The reason I care is I see posts about Vaadin portlets in Liferay that imply that some features are not available for JSR-168 portlets... It may also be that some logic in Liferay switches based on which version of portlet.xml it sees, but I haven't confirmed that either so that would be interesting information too, but not the answer to my question.
According to this doc, but it's also mentioned in jsr286:
The JSR 286 spec(Portlet 2.0) does not break binary compatibility with JSR168(Portlet 1.0). This means that all portlets written against the Portlet 1.0 specification can run unchanged. The only exceptions to this rule are:
renderResponse.setContentType is no longer required before calling getWriter or getOutputstream. In JSR168, calling getWriter or getOutputstream without previously setting the content type resulted in an IllegalStateException.
getProtocol for included servlets / JSPs returns ‘HTTP/1.1’, In JSR168, it returned null.
So as long as your jsr168 portlet doesn't depend on the value returned by getProtocol() you're safe (ie every jsr168 portlet is a jsr286 portlet).
The posts you see seem to be logical as jsr286 is a newer spec and there are some features that make jsr268 portlet not a jsr168 portlet.
Ok, Since I've not found anything new that distinguishes a 2.0 portlet from a 1.0 portlet (aside from using additional services and ) I'll begin the lists for my answer here.
Must Do:
Conform to the 2.0 XSD for portlet.xml (xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd")
Must Not Do:
Rely on getWriter throwing an exception if renderResponse.setContentType has not been called yet. (Seems unlikely anyway)
Rely on getProtocol() returning null
The upshot is, if you simply convert your portlet.xml, you are now "286 compliant" unless you relied on the two items in the second list for your program flow. I can't find anything else, but if someone finds another item for these lists, please edit.
I have an XSD that's going through a transition from one set of elements to another. During the transition, there'll be code expecting the new elements and code expecting the old elements. Therefore I need to keep the old elements in the XSD; I'm documenting them as deprecated (using free text in an xs:documentation element).
Is there a way of marking an element as deprecated such that a tool like xmllint will automatically warn if someone uses a deprecated element?
Create a new schema, with a new namespace. Call this "version 2". If you choose to support version 1 XSD and version 2 XSD in your application that's fine, but keep them seperate and don't try to layer the two on top of each other - especially if you're going try to stop people from using the version 1.
This is worth looking at as it describes some of what you're dealing with:
archive of http://www.pluralsight.com/community/blogs/tewald/archive/2006/04/19/22111.aspx
I realise, however, that doesn't really address your question. With regard to "is there a way to do this?" the answer is "no - not in a universally supported manner". I've seen people add their own doc annotations to give hints, but this isn't going to be universally understood by tooling.
Your best bet in the long run is to create come up with a versioning story for your schema(s) and keep version 2 seperate from version 1.
Is there any way to enforce a template in Bugzilla to guide users fill in bugs descriptions ?
Actually, i'd like to put some markup texts in the bug description field and avoid the creation of custom fields.
I've installed version 3.2rc1.
Indeed, just check ../enter_bug.cgi?format=guided , which forms an example of the template feature. Half the work is already done for you.
The mechansism described under 6.2.5 Particular Templates (under the section called bug/create/create.html.tmpl and bug/create/comment.txt.tmpl) works pretty well for us. Even though you say you don't want to create custom fields, adding some arbitrary HTML is easy enough.